Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 743 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What happened to NAT-T settings in 7.005?

LewisRosenthal
I'm in the process of deploying a new ASL box with over a dozen S2S IPSec VPNs. I have a couple which stubbornly refuse to traverse. The VPNs were working with BorderManager S2S (remotes are SonicWALL TZ170 units, with 3.1.3.0 firmware). There is a second tunnel in each unit which seems to traverse just fine, so I must suspect that it is something on the ASL side of the connection.

The docs refer to the NAT-T settings (with which I am familiar from using v6). The online help, however, does not.

Thoughts?

TIA


This thread was automatically locked due to age.
Parents
  • 0
    I hate to reply to my own post, but this surely does look like what is described here: https://lists.strongswan.org/pipermail/users/2005-August/000901.html

    That said, I rolled the configuration in the SonicWALL back to the BorderManager setup, re-created the tunnel in BorderManager 3.8, and it came right up (the BorderManager server and the new ASL box are on the same T1 connection - not behind a NAT on this end, however).

    Perhaps there is something going on with the box in between on the remote side which is munging the packets (and inserting its own local IP in the mix). But then, why doesn't BorderManager complain? More from the ASL live log:

    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: ignoring Vendor ID payload [da8e937880010000]
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: ignoring Vendor ID payload [404bf439522ca3f6]
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: ignoring Vendor ID payload [XAUTH]
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-00/01: peer is NATed
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work.
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: Peer ID is ID_IPV4_ADDR: '192.168.1.103'
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: we require peer to have ID '***.***.***.***', but peer declares '192.168.1.103'
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: sending encrypted notification INVALID_ID_INFORMATION to ***.***.***.***:500
    2007:06:25-21:32:10 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: Informational Exchange message must be encrypted

    I don't know if this is a problem on the ASG-side or in the middle. I do know that the Sonic tunnel (the second S2S VPN configured in the unit goes back to a SonicWALL concentrator) comes up with NAT-T enabled or disabled in the TZ-170, as does the tunnel when I roll it back to the BorderManager configuration.
  • 0 in reply to LewisRosenthal
    I figured it out...

    The key is in the log (of course):

    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: Peer ID is ID_IPV4_ADDR: '192.168.1.103'
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: we require peer to have ID '***.***.***.***', but peer declares '192.168.1.103'


    All I needed to do was add the SonicWALL's routed IP on its WAN interface (192.168.1.103) as the VPN ID in the Remote settings in ASG. As soon as it stopped tryign to match the public ID (the default), and instead matched on the IP I gave it as the VPN ID, the tunnel came right up.

    As for the other two which were troublesome, the exact same solution applied.

    Problem solved (though I still do not see an option to turn NAT-T on and off in v7 - it appears to be on by default...or if detected on the either end).
Reply
  • 0 in reply to LewisRosenthal
    I figured it out...

    The key is in the log (of course):

    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: Peer ID is ID_IPV4_ADDR: '192.168.1.103'
    2007:06:25-21:31:59 (none) pluto[14841]: "S_REF_AmOtPcNNHa_0" #298: we require peer to have ID '***.***.***.***', but peer declares '192.168.1.103'


    All I needed to do was add the SonicWALL's routed IP on its WAN interface (192.168.1.103) as the VPN ID in the Remote settings in ASG. As soon as it stopped tryign to match the public ID (the default), and instead matched on the IP I gave it as the VPN ID, the tunnel came right up.

    As for the other two which were troublesome, the exact same solution applied.

    Problem solved (though I still do not see an option to turn NAT-T on and off in v7 - it appears to be on by default...or if detected on the either end).
Children
No Data
Cookie Information Banner