OPNsense Forum
Archive => 18.7 Legacy Series => Topic started by: PatrickM on October 19, 2018, 11:49:48 am
-
I've setup an IPsec tunnel between OPNSense and a remote Watchguard box. After some initial configuration woes i believe it's working correctly now.
I have three LAN subnets on the OPNSense box. The IPsec tunnel connects one of the subnets (192.168.142.0/24) to a remote network (10.1.0.0/16). In the firewall settings, I've grouped 'trusted' devices (all LANs + IPsec) and created a rule that allows traffic if source is 'trusted'. This allows devices on any of the LANs to reach each-other and the LAN that is part of the tunnel can reach hosts on the other end. Eventually all LANs will be using the tunnel but i'm currently just in testing stage.
I can't yet access hosts on the OPNSense side of the tunnel, from the other end. Example: from my machine I can ssh to a remote node via the tunnel but can't ssh back into my machine from that host. This could well be a firewall issue on the remote side (which i don't control). Or would it require something on my side? As a test i created a rule that allows any traffic if source is ipsec, which didn't make a difference.
The more immediate issue is accessing hosts on the other end, from the OPNSense box itself. I need this specifically to forward DNS requests for a certain domain to a remote DNS server. I will likely also add monitoring of remote hosts to monit on OPNsense box in the future. I've read some posts about issues in the freeBSD kernel related to routing IPsec traffic. But it's unclear to me if i'm affected by this, if there's some config mistake on my end or an additional (manual) route / fw rule is required. Note i don't really need to access the remote IPsec endpoint itself, but hosts in the remote network.
When I run 'ping -S [lan-ip] [remote-ip]' i do reach remote hosts. But without the '-S [lan-ip]' it doesn't work. I can't bind unbound to a single LAN interface since it also needs to answer requests for the other LANs. Should i create a static route? "System > Routes > Status" shows a route is in place for the remote network on the WAN interface. But when i run 'route -v show [remote-ip]' it appears to goes out directly via the default (isp) gateway with no mention of enc0 or ipsec which seems fishy but maybe normal?
Please bear in mind i'm new to OPNsense (a rookie mistake is quite possible / likely).
-
Currently using a workaround that involves sending the relevant ip as secondary DNS server in DHCP responses. But it's not pretty, results in longer lookup times and extra load on the primary DNS server. And it works for DNS only not for other ipsec remote hosts i plan to add to monit etc.
There must be a better way to resolve this?
-
Took some screenshots of firewall logs, maybe helpful?
The command used is 'dig host.domain.tld @10.1.0.2' (should resolve to 10.1.0.3)
First, executed on OPNsense, without any (manual) static route. The src addr gets set to the WAN IP. The request fails, i assume at our ISP gateway which drops private networks.
Second, the same thing executed on a LAN host behind OPNsense. Works as expected, src addr is set to the LAN host IP.
Third, executed on OPNsense after adding a gateway and static route. The log looks similar to the previous one except the src addr is set to the firewall LAN IP. As expected, using the new gateway and static route. Looks fine to me except that the request fails. :(
Something else I noticed which may be relevant: with the static route and gateway in place, a ping -S 192.168.142.1 10.1.0.2 fails. Without the route/gateway it works fine.
I've come across some threads on the pfsense forum that describe the exact same problem, i.e. this one: https://forum.netgate.com/topic/118667/resolved-ipsec-tunnel-ok-but-routers-can-t-ping-each-others so maybe some change between pfsense / opnsense regarding ipsec is responsible for the difference in behaviour?
-
And another piece of info after doing some network captures: A lookup from the firewall itself doesn't cause any ESP packets to leave out the WAN interface (just some ISAKMP traffic). A lookup from a LAN host does show an ESP packet going out and response coming in, presumably wrapping the DNS request. Note NAT-T was disabled during this test.
This implies the issue is with ipsec routing in my OPNsense host, not some firewall rule or mis-configuration on the other side of the tunnel.
-
Is there really nobody able to help me out with this? It doesn't seem like a complex usecase... Maybe i should try commercial support? But I may just get a "nope, sorry can't be done" answer which would suck....
-
When your WAN IP wants to access internal IPs of the remote side you have to add a P2 SA for this.
WAN-IP/32 - RemoteSubnet
I have this working with a LDAP connection so FW can reach customer internal LDAP ..
-
Ok that makes sense come to think of it... Thanks for the hint!
I've added a Phase-2 entry but the tunnel doesn't come up, presumable because I need a matching entry on the other end :(
-
Thats it ...