4

I'm attempting to connect to a VPN (L2TP over IPsec) server through (not to) a WatchGuard XTM 505 appliance.

I have the VPN server setup behind the firewall on a 1-to-1 NAT, and other protocols (such as HTTP traffic) are forwarded to that server just fine. Also, VPN connections to the machine work perfectly from behind the firewall (i.e. from the LAN).

I've made "Enabled and Available" the following policies to the VPN server:

  • L2TP (opens UDP 1701)
  • IPsec (opens UDP 500, UDP 4500, AH and ESP)
  • PPTP (opens TCP 1723 and GRE)

Yet whenever connecting from outside, I see the following logs from the XTM console:

2011-12-27 16:24:08 iked ******** RECV an IKE packet at 1.2.3.4:500(socket=11 ifIndex=4) from Peer 123.123.123.123:48165 ********   Debug
2011-12-27 16:24:08 iked IkeFindIsakmpPolicy: -->   Debug
2011-12-27 16:24:08 iked Failed to find phase 1 policy for peer IP 123.123.123.123      Debug
2011-12-27 16:24:08 iked IkeFindIsakmpPolicy: <--   Debug
2011-12-27 16:24:08 iked ike_process_pkt : IkeFindIsakmpPolicy failed       Debug

So it seems as if the Firebox is not forwarding this traffic to the 1-to-1 NAT as it should be; rather it seems to attempting to act as the VPN server itself, intercepting the IKE request (but failing because I haven't configured it for VPN).

What am I missing? Is there some setting to force the firewall to forward VPN connection attempts along the NAT? Do I have to pre configure some sort of tunnel between the firewall and the VPN server? Perhaps I need to add a static route of some sort?

Chris Tonkinson
  • 465
  • 2
  • 6
  • 18

2 Answers2

0

I know this is very old thread and probably has been resolved by now, but if you're running old T30 / T50 firebox and still having this L2TP connectivity issue, try this:

  1. Go to Global VPN Settings on your dashboard
  2. Uncheck "Enable built-in IPSec policy".

Providing everything else is configured correctly this should do the trick.

enter image description here

dwurf
  • 910
  • 8
  • 15
Vadim M
  • 1
  • 1
0

In VPN -> VPN Settings, there is an IPSec pass-through option that must be enabled:

It appears that WatchGuard intends this to be used for outbound IPSec VPN connections (from LAN clients to WAN endpoints). To make this work for inbound connections, at minimum you will need to modify the automatically generated IPSec rules to allow inbound connections instead of or in addition to outbound connections.

I would also suggest setting a policy-based NAT on your IKE rule for UDP port 500.

Reference: WSM Manual

Skyhawk
  • 14,149
  • 3
  • 52
  • 95
  • Both enabling IPsec Pass-through and modifying the IPsec policy to allow incoming connections have already been attempted (and, in fact, both of those configurations were effect when the above logs were generated). – Chris Tonkinson Jan 05 '12 at 20:17
  • OK. Did you try the policy-based NAT? – Skyhawk Jan 05 '12 at 20:17
  • By policy-based NAT, are you referring to the "Dynamic NAT" option under the "Advanced" tab in the policy details? If so, I have both 1-to-1 NAT and Dynamic NAT enabled. – Chris Tonkinson Jan 05 '12 at 20:19
  • On the inbound rule that allows traffic for port 500, set the destination IP address to a NAT (choose NAT in the drop-down list instead of Host). For example, if the external IP address is 203.0.113.34 and the internal IP address is 192.0.2.49, the destination column in Policy Manager will say "203.0.113.34 -> 192.0.2.49" if you have configured a policy-based NAT. – Skyhawk Jan 05 '12 at 23:20
  • I'll try this as soon as I get back to my Firebox... in the meantime, what's the difference between allowing traffic to the host (as I've done) and allowing the traffic to a manual NAT definition (as you've suggested) which to me sounds just like re-writing the NAT policy that's already there? To be clear, I'm not doubting you (I haven't tried this approach yet) I'm just trying to understand why it will (or you believe it will) work. – Chris Tonkinson Jan 06 '12 at 00:20
  • Just to clarify: what I currently have is I've defined a 1-to-1 NAT, and I have an alias for the host, which is defined by the external IP of the NAT. So, that alias is what I choose from the host menu when I'm creating policies. To me it seems like defining the policy to a NAT isn't very DRY - what's the point of having that NAT? Or are they being used in complementary and non-overlapping ways? – Chris Tonkinson Jan 06 '12 at 00:24
  • 1
    Didn't work. Same IKE log messages as before. – Chris Tonkinson Jan 06 '12 at 13:30
  • 1
    Bizarre. Has Watchguard support weighed in? (p.s. If you are looking for a firewall that's beauiful like a clean Rails project, WatchGuard isn't it. Try Palo Alto Networks.) – Skyhawk Jan 06 '12 at 18:59