Since GeoIP block targets all incoming connections, administrators of system with complex firewall rules might decide to create a GeoIP group for each remote service (tested with IPsec and OpenVPN). The WebUI allows adding firewall rules for incoming traffic to these ports (and adding another one afterwards which drops all incoming traffic). These rules _do not_ have any effect at all; remote access is still possible for any IP address. In my opinion, this is a security issue as it does not become clear these rules will not work (traffic must be accepted in a previous iptable chain).
I do not understand what you are trying to say. Can you provide a screenshot of an example or iptables output?
Hm, maybe some steps to reproduce are more helpful here: (a) Run IPsec/OpenVPN on a firewall with GeoIP block disabled. (b) All incoming connections from RED to IPsec/OpenVPN service are now allowed. (c) Create a GeoIP group consisting of one or more countries. (d) Create a firewall rule for allowing incoming traffic from RED to IPsec/OpenVPN port if source IP address is located in a country listed at the created GeoIP group in (c). (e) Create another rule for dropping any incoming traffic from RED. (f) Reload firewall rules. (g) Attempt to connect to IPsec/OpenVPN port from an IP located in a different country. My intention of the last stetps' result is packets are dropped as they do not match the GeoIP group. The actual observed result is packets pass to the service. It seems like the firewall rules in (d) and (e) do not have any effect. Let me know if further information is required. :-)
Okay, got it. This is not a bug. This is how the firewall is designed. The GeoIP rules on the extra page are being processed first. The OpenVPN rules, IPsec and also Tor are coming after that. They are automatically created and open those services globally. User-defined rules are coming after that. If you want to limit access to the VPN services (I do not think that Tor makes any sense), then you have to add that to the individual services.
(In reply to Michael Tremer from comment #3) > Okay, got it. This is not a bug. This is how the firewall is designed. Hm, if I may comment on this, I think the firewall design should be improved here. > > The GeoIP rules on the extra page are being processed first. The OpenVPN > rules, IPsec and also Tor are coming after that. They are automatically > created and open those services globally. > > User-defined rules are coming after that. > > If you want to limit access to the VPN services (I do not think that Tor > makes any sense), then you have to add that to the individual services. Okay, I see. However, on a firewall system running a Tor relay, GeoIP block becomes unusable for filtering traffic to IPsec/OpenVPN ports, as it would also affect Tor. :-( Do you see a good way to solve this problem? Anywany, I am assigning this to me as a "feature request", so it stays open.
(In reply to Peter Müller from comment #4) > (In reply to Michael Tremer from comment #3) > > Okay, got it. This is not a bug. This is how the firewall is designed. > Hm, if I may comment on this, I think the firewall design should be improved > here. > > > > The GeoIP rules on the extra page are being processed first. The OpenVPN > > rules, IPsec and also Tor are coming after that. They are automatically > > created and open those services globally. > > > > User-defined rules are coming after that. > > > > If you want to limit access to the VPN services (I do not think that Tor > > makes any sense), then you have to add that to the individual services. > Okay, I see. > > However, on a firewall system running a Tor relay, GeoIP block becomes > unusable for filtering traffic to IPsec/OpenVPN ports, as it would also > affect Tor. :-( You could simple move TOR in front of the GeoIP filter. Indeed there is no point in having it after. Then, the GeoIP filter will apply to the VPNs. I guess that is a simple and also easy to use solution. > Anywany, I am assigning this to me as a "feature request", so it stays open. Yeah, that is fine.