Sorry but still doesn’t block…
I tried again to DROP connection with:
- Source: “GREEN” and Destination: “GeoIP IPSec access” → still access to IPSec VPN
- Source: “IPSec RW” and Destination: “GeoIP IPSec access” → still access to IPSec VPN
As I wrote in the edit section, proxy?
No proxy at all…
Just to make sure I understand. You want to have a tunnel to your IPFire from your road warrior connections, and you want that these tunnels will not be able to connect to any IP not belonging to the two countries you care, regardless of the protocol (mail, web etc.).
Did I understand correctly your problem?
He would only allow incoming RW connections from countries X and Y.
You can use the global location filter to block all incoming connection.
Yes right, only access from 2 countries.
But when enabling “Global Location Filter” to block all incoming connections then our Web-Server will not be accessible to other countries, right ?
Well yes, give only 2 countries login-acces to IPSec and OpenVPN tunnel.
The problem is when blocking all other countries in “Location Block” they will never access our Web-Server…
Maybe I’m paranoid but does it make sense to do a GeoIP-access to IPSec or OpenVPN ? Or are there any security risks when it’s open for everyone ?
Yes.
Ok you need a solution over firewall rules. Try a rule like this source “geo-location x” → destination: red for port 500 and 4500
Ah, I misunderstood then. You want to prevent access to your IPFire IPSec server for road warrior connections, FROM any country but those two?
this I believe is the correct answer.
Unfortunately blocking doesn’t work either with “DROP”
- Source: “GeoIP” → Destination: Standard Networks: “Red” | Service groups: (port 500 and 4500)
- Source: “GeoIP” → Destination: Firewall: “Red” | Service groups: (port 500 and 4500)
Do you have a router before with NAT?
No router, direct connection to our ISP (fiber) and RED with static IP-address.
Theres’ a similar post here but needs a script…
I am not so expert on the firewall rules but here is my 2 pence worth.
Normally any new traffic coming in without a forward rule will be blocked.
To make the OpenVPN/IPSec setup easier then when these services are enabled an automatic firewall rule allowing entry is setup early in the firewall chain.
Looking at the flow chart at the end of this wiki page
https://wiki.ipfire.org/configuration/firewall/iptables
it seems that the OpenVPN and IPSec rules for forwarding cannot be overridden in the WUI firewall rules table as they occur earlier although the GEOIPBLOCK seems to occur before the IPSec rules so at least for IPSec the GEOIPBLOCK by country should have worked.
EDIT:
This diagram is a complete image and has not been updated so is missing some new additions. It might therefore not be 100% accurate.
Anyway, if my above thoughts are correct (and that is not guaranteed) then the best bet is to create iptables rules in one of the CUSTOM chains and put that into firewall.local which gets implemented very early in the whole chain.
https://wiki.ipfire.org/configuration/firewall/firewall-local
OK thanks for your explanation, so the script in the above post “Limit OpenVPN access to just 1 country” could help…
Yes, that post covers what you are looking for.
The script though is set up for only one country so you would need to create the same ACCEPT rule again for your second country. Any packets that don’t meet either country would then move on to the LOG and DROP actions.
These would need to be added to the start and stop sections of that file.
It doesn’t harm to do it but it adds more complexity and I am not sure how much it helps.
At least with OpenVPN, if you are using te TLS protection with a ta.key option then that key is used to encrypt the setup of the control connection, even before any data is transmitted. So any hacker would not only have to be able to break the data cipher but before they can even try that they would have to break the Transmission Channel setup encryption.
I occasionally see attempts at accessing my OpenVPN port but they are immediately stopped as they don’t have a ta.key so IPFire won’t even start to talk to them about setting up the OpenVPN Channel and I never see any attempts to break the data cipher as they would have had to break the ta.key first.
The default IPFire setup re-negotiates that ta.key every hour so that also puts a boundary on the time to break that encryption.
2 Likes
OK thanks again for the explanation…so I think I will leave it as is and maybe one day it will be (hopefully) implemented in ipfire without using a script.
And I didn’t know about the extra security with “TLS Channel Protection” for OpenVPN.
I enabled it but I need to recreate the OpenVPN clients since connection fails…
Don’t forget to hit apply in the firewall rules. Been caught out by that one before.
Other question is… are the VPN rules sitting before the geo-ip rules in the chain.
If they are it does not matter what you put into your firewall hits, they will hit the higher rule and exit.
BR
Joe.