IPSec-DMZ-zone and routing/trafic between DMZ and LAN
-
Yes, when I take down the IPSec interface (and disable NAT) packets flow as expected to and from the DMZ-zone.
I will investigate what I observe with "package capture".
-
@Nightowl82 said in IPSec-DMZ-zone and routing/trafic between DMZ and LAN:
The remote networks defined in Phase2 are 0.0.0.0/0 and ::/0
Yeah that's not going to work. If you had another gateway to policy route to you could policy route traffic to the LAN over that and that would bypass the traffic selector.
You could also put another node up to handle the IPsec. You could put a transit network between them and set the interface going to that up so inbound traffic was flagged with reply-to and route the outbound connections to the IPsec node.
You can probably have more flexibility if you switch from policy-based to route-based (VTI) with the provider, but VTI does not yet work with reply-to for inbound connections so that is probably not going to work as well as a separate node to handle the IPsec.
I'm also curious to know what VPN provider this is.
-
When I do my disable the IPSEC-tunnel-test: Everything works even with NAT from LAN -> Internet enabled, as long as I add another NAT-rule (Do Not NAT from source: LAN-network -> destination: DMZ-network).
How about this experiment: I select a random PC/server on the LAN as a gateway (for instance 192.168.250.100), and create a Policy based firewall rule on the DMZ-interface (All traffic going for 192.168.250.0/23 via 192.168.250.100). Shouldn't traffic directed at the specific host 192.168.250.100 from any DMZ-host work in theory?
-
@Derelict The provider is a local company, that understood our use-case.
Yes, putting up another node could be a possible solution, we have some IPv4-addresses left after putting up the most necessary hosts. I still believe this should be doable (at least intuitively) with Policy-Based routing on the DMZ-interface. Could there be a way to policy-route traffic out through a specific interface (for instance the LAN-interface) if I go beneath the pfsense-GUI and try directly in the underlying OS?
If I am to specify IPSec-Phase2 for all other networks than the LAN-IPS, could that be a solution?
For instance:
Phase2 (entry 1): remote network 0.0.0.0/1 (IP-range: 0.0.0.0-127.255.255.255)
Phase2 (entry 2): remote network 128.0.0.0/3 (IP-range: 128.0.0.0-191.255.255.255)
Phase2 (entry 3): remote network 224.0.0.0/3 (IP-range: 224.0.0.0-255.255.255.255)
...
...
And so on, so on ...So that I manually specify that all network except the 192.168.0.0-range should be sent through the tunnel? It will be a lot of phase 2 entries, but are there any principal problems with my thinking here?
-
Another thing, I can ping the LAN-IP of the pfsense from a host in the DMZ-zone, while the IPSec-interface is enabled.
temp@test:~$ ping 192.168.250.1 PING 192.168.250.1 (192.168.250.1) 56(84) bytes of data. 64 bytes from 192.168.250.1: icmp_seq=1 ttl=64 time=0.111 ms 64 bytes from 192.168.250.1: icmp_seq=2 ttl=64 time=0.187 ms 64 bytes from 192.168.250.1: icmp_seq=3 ttl=64 time=0.170 ms 64 bytes from 192.168.250.1: icmp_seq=4 ttl=64 time=0.174 ms ^C --- 192.168.250.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 73ms rtt min/avg/max/mdev = 0.111/0.160/0.187/0.031 ms temp@test:~$I also am getting hits on the firewall rules on the DMZ, if I create policy-routing rule to send packets through a fictive gateway (random host, specified as a gateway) on the LAN-NET, but the LAN-machine does not answer my ICMP-packets as long as the IPSec-interface is up. Does the IPSec-setup somehow superseed all the firewall rules, or policy-based routing enteries? Or is there something fundamentally wrong with my understanding of them?
-
It does not matter if you use 0.0.0.0/0, 0.0.0.0/1+128.0.0.0/1, etc. The traffic selectors are still going to snarf up all the traffic.
Policy routing can grab traffic coming into the firewall before IPsec traffic selectors
Then IPsec traffic selectors
Then the routing tableSite-to-site IPsec with 0.0.0.0/0 is almost always impossible to make work as you want it to.
-
@Derelict said in IPSec-DMZ-zone and routing/trafic between DMZ and LAN:
It does not matter if you use 0.0.0.0/0, 0.0.0.0/1+128.0.0.0/1, etc. The traffic selectors are still going to snarf up all the traffic.
How so? My plan was to specify all the global routable IPv4-networks and exclude my private address-space for the LAN-net, in the shortest list I am able to compile, something like this:
The traffic selectors you refer to should then leave my DMZ-> LAN traffic alone, since my LAN-net is not sepcified in any phase 2 entry as a remote network.
Only one way to find out: I will ask my provider if this causes any problem in their end and do an experiment.
Policy routing can grab traffic coming into the firewall before IPsec traffic selectors
Then IPsec traffic selectors
Then the routing tableAre you sure things are processed in this manner?
Then it should be doable with policy based routing.
As far as I can see, when I investigate the matter more deeply: The packet-filter policy routing rule that is generated in my experiment is the following:
pass in quick on [DMZ-interface] route-to ([LAN-INTERFACE] 192.168.250.25) inet from [DMZ-net].40/29 to 192.168.250.0/23 flags S/SA keep state label "USER_RULE"And if one looks up the pf.conf-man-page for the route-to option:
"route-to
The route-to option routes the packet to the specified interface with an optional address for the next hop. When a route-to rule creates state, only packets that pass in the same direction as the filter rule specifies will be routed in this way. Packets passing in the opposite direction (replies) are not affected and are routed normally."It seems like the gateway in route-to is optional, and that it sould be possibe to specify just an outgoing interface for my packets. So maybe policy routing rule like this would do what I want?:
pass in quick on [DMZ-interface] route-to [LAN-INTERFACE] inet from [DMZ-net].40/29 to 192.168.250.0/23 flags S/SA keep state label "USER_RULE"Maybe this can be done through editing the ruleset-generator, as suggested here:
https://docs.netgate.com/pfsense/en/latest/firewall/editing-the-pf-ruleset.html
-
I have done some new experiments:
1.) I tried to set up a router in my LAN-net, with the NET 192.168.0.0/24 with a host 192.168.0.10 on the other side. I have then configured policy based routing in the DMZ so that any traffic going to 192.168.0.0/24 are supposed to go through the gateway on 192.168.250.25 (In the LAN-net).
This still won't work when IPSec is connected. If my policy based routing setup was working as it should, and the policy based routing happens before the IPSec-system takes control over my packages, why won't this setup work?
2.) I tried to create a policy based routing rule for the LAN-interface in an attempt to send traffic for the DMZ via my ISPs gateway, so that it would find a way back through the DMZ via the IP-provider's tunnel.
This almost worked, the packages went out to the internet, but didn't seem to be able to get back from the DMZ. Maybe because of some confusion when it comes to NATing, the outgoing traffic from the LAN-interface would seem to come from the WAN-interface from the perspective of the host.
But it seems like my understand of the policy-based routing rules seems to be ok.
-
@Derelict The test with 16 phase 2 entries worked like a charm. Everything seems to behave as I want it, I have full connection back and forth between the DMZ-net and the LAN-net. The LAN connections to the internet goes through the Normal WAN-interface, and everything to and from the internet in the DMZ goes through the IP-Sec-tunnel.
An ugly setup/configuration, and I am not sure if it will causes problems or challenges in the other end (or for our own setup) further down the road. And I still prefer to establish a solution with a policy based routing configuration.
I am also at the moment not certain how to approach IPv6. That will probably be a LOT of entries to achieve the same pressision! But it might be enough to just route the global internet through the tunnel (2::/3 AS the remote endpoint in phase2), at least for the time being, since my ISP don't provide global-routable IPv6-addresses for our internal network anyway.
After some more reasearch it seems that a preatier solution able to solve all my troubles might be to use "Routed-IPSec" as explained here:
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ipsec-routed.html
and for mye provider’s side here:
(This would consume a transport-NET worth of IP-addresses more from my provider’s part)
-
Update1: I have together with my IP-provider tried to get an routed/VTI IPsec configuration up and running.
I was able to make it work between two pfsense boxes on a local LAB, but not between my ISPs Fortigate and my local pfsense.
We are getting an log entery like this in our pfsense box:
received an sadb_acquire with policy id 2 but no matching policy found( sadb_acquire is explained more in detail here: https://tools.ietf.org/html/rfc2367#section-3.1.6 )
Matched with a time-out in the Fortigate logs. So at least for this version of pfsense, no go for routed/vti-based ipsec.
-
Update2:
Another approach is to make conventional tunnels work, what I need is a way to exclude traffic between our LAN-NET and DMZ-NET from being sent into the tunnel when the remote network is set to 0.0.0.0/0 and 0::/0. The remote network need to be 0.0.0.0/0 (and NOT 192.168.0.0/16)
I have found some comments on similar feature requests in different setups, like here:
https://redmine.pfsense.org/issues/3329
But I can also see that in the underlying strongswan-deamon it should be possible, like described here:
https://serverfault.com/questions/903211/exclude-a-local-subnet-from-strongswan-vpn/903315
Or through a strongswan-plugin described here:
https://wiki.strongswan.org/projects/strongswan/wiki/Bypass-lan
This plugin is discussed in a pfsense-context here:
https://forum.netgate.com/topic/134445/ipsec-bypass-lan-does-not-work-plugin-missing
Is there a way to manually make this work on a pfsense box, circumventing the GUI to configure strongswan directly?
Any help/tips would be greatly appreciated.
-
Working solution: I was finally able to get what I wanted, by manipulating the strongswan config manually, and restart IPSec.
PFSense already has a bypass LAN setting, that can be checked and unchecked in it's IPSec-config, so my solution is just to edit the list of networks that have status as "Shunted".
Can be done via the GUI: Diagnostics -> Command Prompt -> Paste Command -> Execute
(Using sed to replace the relevant lines in the strongswan-config-file and restart ipsec)
sed -i '' -e 's#192.168.250.0/23,fdd0:192:168:250::/64#192.168.250.0/23,[DMZ-IPv4-NET]/29,fdd0:192:168:250::/64,[DMZ-IPv6-NET]/64#g' /var/etc/ipsec/ipsec.conf ipsec restartIf one runs ipsec statusall, then all necessary networks (both LAN-to-LAN, and DMZ-to-LAN) will be listed under "Shunted Connections".
