[17.7 alpha, 17.1] Firewall cannot reach far subnet via IPSec, clients can

[obrienmd]

I have 3 sites: 192.168.90.0/24 (opnsense .1) 192.168.91.0/24 (opnsense .1) 192.168.110.0/24 (opnsense .1)

Hosts on any of the nets can reach each other, but the opnsense hosts cannot reach each other - I have tested ICMP, UDP (DNS) or TCP (HTTP) services.

Strangely, the routing tables (netstat -r) on each shows the default gateway as the next hop for far subnets. For example on 192.168.110.1: 192.168.90.0/24 my-default-wan-gw-ptr US igb0 (the wan if) 192.168.91.0/24 my-default-wan-gw-ptr US igb0 (the wan if) 192.168.110.0/24 link#9 U bridge0

This is OK for now, but these devices rely on each other to to cross-location DNS lookup, which is currently not working. Thanks for any help!

[fichtner]

Hi Michael,

This may be a restriction of the kernel handling IPsec subnet matching. It wants perfect matches or discards the traffic. At least one user worked around this by adding HAProxy into the directly connected subnet at the remote site passing the traffic on.

Maybe @fraenki can shed more light on this.

Cheers, Franco

[obrienmd]

Thanks for the explanation!

Does pfSense work around this with a patch of some sort? I don't recall this same issue when using it, even on FreeBSD 11.x-based dev branch.

[fichtner]

@obrienmd maybe through nat before ipsec? it required custom patches

[obrienmd]

Interesting - I'd have to go look through configs, but I don't think that was the case. Regardless, this environment's sticking with IPSec. Do you know if this is something that has a bug report open in FreeBSD core?

[obrienmd]

Do the NAT changes in FreeBSD 11.1 make any difference here: https://lists.freebsd.org/pipermail/freebsd-stable/2017-June/087242.html

[fichtner]

NAT before IPsec and / or additional SPDs are coming to 17.7.1, for more details see https://github.com/opnsense/core/issues/440

[obrienmd]

Great, thanks!

-- Mike OBrien 253.217.7129

On Sat, Aug 5, 2017 at 3:30 PM, Franco Fichtner notifications@github.com wrote:

NAT before IPsec and / or additional SPDs are coming to 17.7.1, for more details see #440 https://github.com/opnsense/core/issues/440

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/1624#issuecomment-320473946, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWl94UGFyWTQN7QbQ8E0ha_bU5VdC3xks5sVO0YgaJpZM4NTQXO .

[ruffy91]

I am on 18.7 I cannot ping the remote IPsec Firewall from the OPNSense firewall. So I can Ping:

• Local Clients to Remote Clients
• Local Firewall to Remote Clients
• Remote Firewall to Local Clients
• Remote Clients to Local Clients

But whenever pinging Local Firewall to Remote Firewall the traffic exits on the WAN interface directly instead of through the matching IPsec tunnel. Is there a workaround or solution to this?

[fichtner]

@ruffy91 what is "local firewall"? ipsec spd prevents accepting traffic from unknown sources. you need to set "Manual SPD entries" in your phase 2. it's impossible to help further without stating network layouts.

[ruffy91]

Hello Franco, Local Firewall: OPNsense 18.7, LAN 10.0.1.1/24, WAN PPPoE Remote Firewall: Sophos UTM, LAN 10.0.2.1/24, WAN static Tunnel Phase 2: 10.0.1.0/24 <-> 10.0.2.0/24 Ping from 10.0.1.1 to 10.0.2.1 goes out the PPPoE WAN on Local Firewall

[fichtner]

which ping method do you use? console or GUI?

[ruffy91]

OK I understand now, the source address has to be in the SPD and routing does not apply to traffic from the firewall itself. When selecting source address within spd (LAN address) it works on both shell and GUI (not on console, because I cannot select the source address there). But with monit I cannot select a source adress for checks.

[fichtner]

ok glad to hear. in raw command line ping utility takes the source parameter -S if you ever need to troubleshoot manually :)

[ruffy91]

Yes, on the shell, but option 7 (ping host) in console does not. I will open an issue with the monit plugin to add a source address option for the rest. Thank You