Accessing Firewall Services over IPsec

With an out of the box configuration it is not possible to query SNMP or other similar services on the LAN interface address of a remote firewall running pfSense® software over a tunnel mode IPsec VPN connection.

Note

Most of the advice in this document only applies to tunnel mode, not routed IPsec (VTI). See Routed IPsec (VTI) for details.

Fred Wright explained in a post to the m0n0wall mailing list on September 12, 2004 why this is, and it’s the same reason here.

Due to the way IPsec tunnels are kludged into the FreeBSD kernel, any traffic *initiated* by m0n0wall to go through an IPsec tunnel gets the wrong source IP (and typically doesn’t go through the tunnel at all as a result). Theoretically this *shouldn’t* be an issue for the *server* side of SNMP, but perhaps the server has a bug (well, deficiency, at least) where it doesn’t send the response out through a socket bound to the request packet. You can fake it out by adding a bogus static route to the remote end of the tunnel via the m0n0wall’s LAN IP (assuming that’s within the near-end tunnel range). A good test is to see whether you can ping something at the remote end of the tunnel (e.g. the SNMP remote) *from* the m0n0wall. There’s an annoying but mostly harmless side-effect to this - every LAN packet to the tunnel elicits a no-change ICMP Redirect.

Most notably this is a problem for UDP services bound to all interfaces (*) and ICMP. In these cases, a reply uses the “closest” address to the client from the perspective of the system routing table. Without a route present matching the desired destination this results in using the IP address of the interface containing the default gateway.

Service Binding Workaround

Some services have options which make it possible to change the interface binding so that the daemon only binds to a specific interface or IP address (e.g. the IP address of the internal network on the local end of the VPN) on the firewall. The interface binding for SNMP, NTP, the DNS Forwarder, and several other services can be set in this way.

With the daemon bound to only that specific address, that is also the only address it can use to reply, and thus it can generate the expected replies which will properly take the IPsec path back to the other end.

Static Route Workaround

If changing the service binding is not possible, or for full connectivity between the endpoints, use static routes to work around the situation.

Note

When both endpoints must be accessed, a static route is required on each endpoint.

Setting up a static route is done by first adding a gateway pointing to the LAN IP address of the firewall (See Gateways) and then adding a static route using this gateway (See Static Routes).

Warning

Do not attempt to use this method with routed IPsec (VTI). See Routed IPsec (VTI) for details.

Add Gateway

First, add a gateway for the address of the firewall itself:

  • Navigate to System > Routing on the Gateways tab

  • Click fa-plus Add to add a gateway

  • Configure the following settings:

    Interface

    LAN

    Name

    IPsecGW or another appropriate name, as desired.

    Gateway

    Enter the LAN IP address of this firewall.

    Disable Gateway Monitoring

    Checked

  • Click Save

  • Click Apply Changes

Add Route

Now add this route in the GUI:

  • Navigate to the Static Routes tab

  • Click fa-plus Add

  • Configure the following settings:

    Destination Network

    The remote VPN network

    Gateway

    IPsecGW or whichever name was used when creating the gateway

    Description

    Allow firewall itself to communicate over VPN

  • Click Save

  • Click Apply Changes

Test

Perform a test as described in Testing IPsec Connectivity using the address of the far side system and the local address that system is attempting to query.

Routed IPsec (VTI)

The previous advice in this document does not generally apply to route-based IPsec (VTI mode) since it operates in a fundamentally different way than policy-based IPsec (tunnel mode).

With VTI mode IPsec the routing table contains proper routes back to the remote end using the VTI interfaces. Responses will utilize these routes to select the IPsec interface when looking up the path back across the tunnel.

This may mean the remote end should query the address of the IPsec interface directly so that the responses are received from a matching address, but whether or not this is necessary depends on the service and client.

The Service Binding Workaround can still help here if queries must be made to and from the LAN IP address directly, but the static route method must not be used as it will conflict with the routing necessary for VTI traffic to function.