IPsec routing workaround for pfsense own ip causes issues with SLES11.

[ccdmas]

Hi.

There is this really old issue with ipsec where pfSense itself can't reach remote IP addresses (which is a pain), and this kludge as workaround:

https://doc.pfsense.org/index.php/Why_can't_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN?

However, after I implemented this, all Linux (SLESS11 in my case) servers can no longer communicate through the IPSec tunnels (pfSense being the default GW for all machines), whereas Windows and also VMWAre ESXi still can. Doing a traceroute on the linux boxes return five rows of no responses, and the sixth row sees the linux box reply to itself, then it gives up.

Apparently SLES really hates the additional ICMP redirect that it receives pointing it to the router it's already using as default GW.

Is there another method to make pfSense communicate properly through it's own ipsec tunnel? First and foremost, I need to have remote pfSense boxes be able to resolve DNS using a DNS server in a network behind the tunnel, and also be able to use NTP to sync time through the tunnel.

I understand this should work if I can make pfSense use it's LAN IP address as source address for the DNS and NTP requests. I haven't been able to find if that's possible, and how though.

Thanks,
ccdmas

[cmb]

Depends on what services you're using as to whether that route is required. For DNS, the DNS forwarder's domain overrides allow specifying a source IP, which negates the need for that route. Any service that lets you choose a source IP will work if you bind it to LAN.

That really shouldn't break SLES, that should probably be reported there as a bug. Should be able to disable acceptance of ICMP redirects on the SLES host to work around it.

[ccdmas]

@cmb:

Depends on what services you're using as to whether that route is required. For DNS, the DNS forwarder's domain overrides allow specifying a source IP, which negates the need for that route. Any service that lets you choose a source IP will work if you bind it to LAN.

That really shouldn't break SLES, that should probably be reported there as a bug. Should be able to disable acceptance of ICMP redirects on the SLES host to work around it.

Thanks for your reply.

As I said, the services I absolutely need to work from pfsense through the tunnel are DNS resolution (not a forwarder, but pfsense itself needs to be able to resolve names, and the name server it needs to talk to is behind the tunnel), and NTP (the NTP server pfSense needs to use to sync it's won time is also behind the tunnel.

As for reportign the SLES behaviour as a bug: No chance in hell this would ever be accepted as such. And I highly doubt it's a SLES specific issue at all. They don't touch the tcp/ip stack. Disabling redirect acceptance unforunately isn't possible here either, it's needed.

Thanks again.