[SOLVED] ipsec: can't send traffic from opnsense, fine from lan network

[anaxagoras]

any device on my network can pass traffic across my ipsec tunnels just fine, but for some reason my opnsense box can't pass any traffic across the tunnel itself, i only discovered this trying to figure out why my opnsense unbound can't forward dns queries across the vpn.


i'm on OPNsense 22.7.7_1-amd64, and it's a relatively fresh install, i just set up the box and built my old tunnels, and put in a few port forwarding rules so far.

EDIT: forgot to add, these are policy based tunnels connecting to pfsense on the remote side.  This worked fine when my local firewall was pfsense.

[Patrick M. Hausen]

Your problem is that there is no IPsec interface so there is no source address for Unbound to pick that is part of the phase 2 SA. Can you configure a query source address for Unbound? I don't know from the top of my head because I run BIND. If yes, set that to the LAN address of your OPNsense.

If not you will probably have to mess with NAT in some way.

HTH,
Patrick

[anaxagoras]

Ahhh, ok, so i was confused about what you said because i was like i can't even run a ping from my opnsense box, but i just did

Code Select Expand

ping -S 192.168.102.1 192.168.3.35, and low and behold it worked and now i think i follow.

I guess what i don't understand is why this doesn't work, is this an ipsec issue? or an opnsense issue.  i thought it worked when i was running pfsense, but i could be wrong.

I just went through the config options in opnsense and no, nothing useful there to bind the source address.  unsure if there are any options in unbound itself that i could manually edit in a config. 

I tried a stab at a few variations of outbound nat rules, so far no luck with anything.

[Patrick M. Hausen]

This is a fundamental problem with policy based IPsec tunnels regardless of the product used.

Unbound tries to reach its upstream resolver following the routing table. The routing table points to the WAN uplink. Therefore the queries are sent out the WAN, but never reach anything because the upstream is only reachable via the tunnel.
You cannot add a route pointing to the tunnel because there is no proper interface for the tunnel in a policy based setup. The kernel just "magically" tunnels all packets matching source and destination for the phase 2 SA(s).


Actually there is a setting that you could try:

Service > Unbound DNS > General > Advanced > Outgoing Network Interfaces

Try to set that to LAN ...


HTH,
Patrick

[anaxagoras]

Service > Unbound DNS > General > Advanced > Outgoing Network Interfaces

Thank you this worked.

You also put me on the path to find another workaround, per this pfsense article
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html

i create a lan gateway, and a static route to pass any traffic to the vpn remote side over the lan gateway, which is also working.

[Patrick M. Hausen]

I agree with the diagnose in that article, but the statement "the way IPsec tunnels are kludged into the FreeBSD kernel" is simply not true. Classical Cisco IOS devices and a ton of gear by other vendors behave in exactly the same way.
I've been implementing IPsec VPNs in "enterprise" environments for more than 20 years.

The cause lies in the policy based tunnel instead of a dedicated tunnel interface.

@franco possibly use parts of that article for our documentation? Or write our own if the pfSense docs are not liberally licensed.

[franco]

Ad and Michael did the bulk of the IPsec documentation, but if anyone else can give a hand that would be nice. Perhaps the best page to put this on is https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html ?

I agree here that the "static route workaround" is actually the graceful way to match the security policy of the non-routed IPsec implementation, same as for other requirements of a specific outgoing address for any type of included service. The routing table was made for this reason and helps a service use the correct outgoing address (even if it listens to a wildcard address).


Cheers,
Franco