Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 1723 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

[7.101]: IPsec-CA authentication + NAT not working

Duke_01
Hi,

we just got a new ASG appliance with 7.101 and I'm not able to get IPsec connections to work which use CA-authentication with (stock WinXP) clients that are behind a NAT. This used to work fine in V6 before. The connection handshake fails with the error "cannot respond to IPsec SA request because no connection is known for 192.168.1.0/24===x.x.x.170:4500[@abc.acme.de]...y.y.y.32:32843[C=de, ...]===172.16.5.15/32".

When looking at the ipsec.conf files from V6 and V7, the only significant difference is that in the V6 config file, there is an entry "rightsubnetwithin=0.0.0.0/0.0.0.0" which is missing in V7. Even more, if I add this line to the "conn %default" section in the ipsec.conf-default file of the ASG 7, the IPSec connection finally succeeds!

What's the deal with this? This looks very similar to a problem I reported against V5 back in 2004: https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/51899. Is this a regression or is there some setting I missed in the several "Advanced" sections that deal with IPSec in the WebAdmin?

Thanks.


This thread was automatically locked due to age.
Parents
  • 0
    The story continues: After contacting our support, it turns out that it's a known issue that IPSec-CA and NAT-T doesn't work - which could have saved us some hours if this was actually mentioned in the *known issues list*. Well, in fact this means that a *major* part of the functionality that the ASG is supposed to provide doesn't work - and there's no qualified statement yet, if/when this will be fixed.

    The next thing is that even after manually fixing that "rightsubnetwithin" option, the ASG still doesn't let any traffic pass the tunnel. This requires a static packet-filter entry that allows traffic from the client's remote (private) network(s). This is quite contrary to the online-help, which says there should be an "auto packet-filter" option - which doesn't exist though. Sure enough, in V7 the ability to create packet filter rules based on DN-patterns doesn't exist any more either. So the only option to get it to work right now is a) to hack some config file for the IPSec-tunnel (which will eventually vanish with the next update) and b) to have a set of static packet-filter rules that actually allow the traffic. Especially b) is not desirable because it will open the packet filter for unnecessarily large networks and also exists independently of whether a tunnel is established or not.

    So, in the current state, I'm tempted to say that the (IMHO not too unusual) combination of the IPSec/CA/NAT-T features is completely broken. I'd appreciate to get some feedback from Astaro about this since this is not just a minor annoyance and the supplier's support hasn't been able to provide any useful information so far either. Thanks.
Reply
  • 0
    The story continues: After contacting our support, it turns out that it's a known issue that IPSec-CA and NAT-T doesn't work - which could have saved us some hours if this was actually mentioned in the *known issues list*. Well, in fact this means that a *major* part of the functionality that the ASG is supposed to provide doesn't work - and there's no qualified statement yet, if/when this will be fixed.

    The next thing is that even after manually fixing that "rightsubnetwithin" option, the ASG still doesn't let any traffic pass the tunnel. This requires a static packet-filter entry that allows traffic from the client's remote (private) network(s). This is quite contrary to the online-help, which says there should be an "auto packet-filter" option - which doesn't exist though. Sure enough, in V7 the ability to create packet filter rules based on DN-patterns doesn't exist any more either. So the only option to get it to work right now is a) to hack some config file for the IPSec-tunnel (which will eventually vanish with the next update) and b) to have a set of static packet-filter rules that actually allow the traffic. Especially b) is not desirable because it will open the packet filter for unnecessarily large networks and also exists independently of whether a tunnel is established or not.

    So, in the current state, I'm tempted to say that the (IMHO not too unusual) combination of the IPSec/CA/NAT-T features is completely broken. I'd appreciate to get some feedback from Astaro about this since this is not just a minor annoyance and the supplier's support hasn't been able to provide any useful information so far either. Thanks.
Children
  • 0 in reply to Duke_01
    While I originally thought that this was still broken in 7.200, it does indeed appear to have been fixed. In addition, there is a NAT option in the advanced settings which I believe was missing in 7.10x and below (I may be mistaken, however).

    Anyway, it's good to see that client-to-site IPSec tunnels are now handling NAT-T as they should (and as they did under v6).
  • 0 in reply to LewisRosenthal
    I get a similar error using shared secret.  I'm new to all this, so I'm not sure what to do.  Any suggestions?

    Thanks,

    ML
  • 0 in reply to mlangas
    I get a similar error using shared secret.
    Is this on 7.10x or on 7.20x?

    What error are you seeing in your log? Depending upon the remote NAT router, you may need to modify the tunnel ID from the default (public address on the remote side) to the LAN side IP of the NAT router, as in:

    [FONT=Fixedsys][ASG] ---------------------------- [NAT Router] ---------------------------- [remote LAN]
                      ***.***.***.***                     192.168.1.1            192.168.1.0/24
                   (remote public IP)                         (private IP)                 (clients)[/FONT]
    Normally, ASG assumes the tunnel ID to be the remote public IP. However, some NAT routers insist upon pushing the private side IP through the tunnel as the ID. In the case outlined above, this won't work, as ASG is expecting ***.***.***.*** (public IP) and instead gets a remote site identifying itself as 192.168.1.1. However,. if you edit the configuration for that tunnel and enter the 192.168.1.1 address for the ID, this will resolve the problem (you may, of course, have to change it at some point should your remote hardware - or firmware! - change).

    HTH
  • 0 in reply to LewisRosenthal
    Lewis,

    I understand your explanation and believe this is what is happening.  It looks like it is probably my NAT router that is doing this however.  I'm going to play with this a bit, but I'm still unfamiliar with Astaro.  Does the code in your example go in an astaro config file somewhere?

    Thanks for the help.
  • 0 in reply to mlangas
    No, you'll enter the VPN ID in the configuration for the tunnel, right through the UI. Go to Site-to-Site VPN | IPSec and then navigate to the Remote Gateways tab. Click the edit button for the tunnel you need to modify. About halfway down the list of parameters, you should see:

    VPN ID Type:IP address
    VPN ID (optional):

    This is where you set the remote ID. Note the following log snippet from Monday, when I had to deal with this very thing, because the remote address had changed from what I had set in ASG:

    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03
    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: ignoring Vendor ID payload [da8e937880010000]
    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: ignoring Vendor ID payload [404bf439522ca3f6]
    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: ignoring Vendor ID payload [XAUTH]
    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-00/01: peer is NATed
    2008:07:21-11:02:50 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work.
    2008:07:21-11:02:51 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: Peer ID is ID_IPV4_ADDR: '192.168.2.102'
    2008:07:21-11:02:51 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: we require peer to have ID '192.168.2.101', but peer declares '192.168.2.102'
    2008:07:21-11:02:51 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: sending encrypted notification INVALID_ID_INFORMATION to ***.***.***.***:500
    2008:07:21-11:03:00 (none) pluto[3841]: "S_REF_nwusNgljSz_0" #45419: Informational Exchange message must be encrypted
    Note the references to the private IP (I have replaced the public IP with x's). My edit, then, was to change the ID in Astaro to match what the Zyxel router (in this case) was passing through, i.e., 192.168.2.102, the "new" address for the SonicWALL VPN router behind the Zyxel DSL router.

    Search your IPSec logs for "Peer ID is ID_IPV4_ADDR" and see if you come up with any hits.

    Good luck!
Cookie Information Banner