Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      ccdmas
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • C
          ccdmas
          last edited by

          @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.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.