Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 23129 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

L2TP vpn failed

MartinBergs

I setup a L2TP over IPsec on my UTM (9.353-4). The interface I bound the VPN is an ethernet bridge interface

The connection from my test clients (iPhone iOS 9.2.1 and Macbook 10.10.5) failed.

|--internal workstation ----- vpn UTM firewall  (ethernet bridged) ----- internet router ----- vpn client (public IP) --|

|------------------------------------ private IPs (192.168.x.x) -------------- | ------------- public IPs --------------|

2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: received Vendor ID payload [RFC 3947]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2016:02:12-21:20:59 dcfw220 pluto[19842]: packet from 62.203.x.x:9333: received Vendor ID payload [Dead Peer Detection]
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[27] 62.203.x.x:9333 #54: responding to Main Mode from unknown peer 62.203.x.x:9333
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[27] 62.203.x.x:9333 #54: NAT-Traversal: Result using RFC 3947: both are NATed
2016:02:12-21:20:59 dcfw220 pluto[19842]: | NAT-T: new mapping 62.203.x.x:9333/4500)
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[27] 62.203.x.x:4500 #54: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[27] 62.203.x.x:4500 #54: Peer ID is ID_IPV4_ADDR: '192.168.x.x'
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: deleting connection "L_for ras-user"[27] instance with peer 62.203.x.x {isakmp=#0/ipsec=#0}
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Dead Peer Detection (RFC 3706) enabled
2016:02:12-21:20:59 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sent MR3, ISAKMP SA established
2016:02:12-21:21:00 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: cannot respond to IPsec SA request because no connection is known for 62.203.x.x/32===192.168.x.x:4500[192.168.x.x]:17/1701...62.203.x.x:4500[192.168.x.x]:17/%any==={192.168.x.x/32}
2016:02:12-21:21:00 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_ID_INFORMATION to 62.203.x.x:4500
2016:02:12-21:21:03 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:03 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:06 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:06 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:10 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:10 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:13 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:13 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:16 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:16 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:20 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:20 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:23 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:23 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:26 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:26 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:30 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x0b624fd9 (perhaps this is a duplicated packet)
2016:02:12-21:21:30 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: sending encrypted notification INVALID_MESSAGE_ID to 62.203.x.x:4500
2016:02:12-21:21:30 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500 #54: received Delete SA payload: deleting ISAKMP State #54
2016:02:12-21:21:30 dcfw220 pluto[19842]: "L_for ras-user"[28] 62.203.x.x:4500: deleting connection "L_for ras-user"[28] instance with peer 62.203.x.x {isakmp=#0/ipsec=#0}

To verify the configuration I test the VPN from the LAN and in this case both test clients can establish the VPN successfully.

|--internal workstation ----- vpn UTM firewall (ethernet bridged) ----- vpn client (private IP) ----- internet router --|

|------------------------------------ private IPs (192.168.x.x) -------------- | ------------- public IPs --------------|

2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: received Vendor ID payload [RFC 3947]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2016:02:12-20:52:53 dcfw220 pluto[19842]: packet from 192.168.x.x:500: received Vendor ID payload [Dead Peer Detection]
2016:02:12-20:52:53 dcfw220 pluto[19842]: "L_for ras-user"[26] 192.168.x.x #52: responding to Main Mode from unknown peer 192.168.x.x
2016:02:12-20:52:53 dcfw220 pluto[19842]: "L_for ras-user"[26] 192.168.x.x #52: NAT-Traversal: Result using RFC 3947: no NAT detected
2016:02:12-20:52:53 dcfw220 pluto[19842]: "L_for ras-user"[26] 192.168.x.x #52: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2016:02:12-20:52:53 dcfw220 pluto[19842]: "L_for ras-user"[26] 192.168.x.x #52: Peer ID is ID_IPV4_ADDR: '192.168.x.x'
2016:02:12-20:52:53 dcfw220 pluto[19842]: "L_for ras-user"[26] 192.168.x.x #52: Dead Peer Detection (RFC 3706) enabled
2016:02:12-20:52:53 dcfw220 pluto[19842]: "L_for ras-user"[26] 192.168.x.x #52: sent MR3, ISAKMP SA established
2016:02:12-20:52:54 dcfw220 pluto[19842]: "L_for ras-user"[3] 192.168.x.x #53: responding to Quick Mode
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Plugin aua.so loaded.
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: AUA plugin initialized.
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Plugin ippool.so loaded.
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Plugin pppol2tp.so loaded.
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: pppd 2.4.5 started by (unknown), uid 0
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Using interface ppp0
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Connect: ppp0 <-->
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Overriding mtu 1500 to 1380
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Overriding mru 1500 to mtu value 1380
2016:02:12-20:52:54 dcfw220 pppd-l2tp[20523]: Overriding mtu 1500 to 1380
2016:02:12-20:52:54 dcfw220 pluto[19842]: "L_for ras-user"[3] 192.168.x.x #53: IPsec SA established {ESP=>0x0d178550 <0xd8982de2 DPD}
2016:02:12-20:52:56 dcfw220 pppd-l2tp[20523]: Cannot determine ethernet address for proxy ARP
2016:02:12-20:52:56 dcfw220 pppd-l2tp[20523]: local IP address 10.242.3.1
2016:02:12-20:52:56 dcfw220 pppd-l2tp[20523]: remote IP address 10.242.3.2
2016:02:12-20:52:57 dcfw220 pppd-l2tp[20523]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="ras-user" variant="l2tp" srcip="192.168.x.x" virtual_ip="10.242.3.2" ras-user

As the VPN is working from the LAN but not from the internet I guess the VPN client and VPN server configuration is correct.

The verify the internet connection I installed a new VPN gateway behind the UTM. The configuration on the VPN test clients have not be changed. The UTM firewall passthrough IKE and ISAKMP. The VPN established with success.

|--internal workstation ----- vpn gateway ----- UTM firewall  (ethernet bridged) ----- internet router (NAT) ----- vpn client (public IP) --|
|------------------------------------------ private IPs (192.168.x.x) ------------------------ | --------------- public IPs ----------------|

So my question is why phase 2 of IKE fail with the error message "cannot respond to IPsec SA request because no connection is known for..."? And how to fix it?

Thanks for your thoughts.



This thread was automatically locked due to age.
Parents
  • 0

    Hi Bob

    Maybe I was to cautious that I obfuscated to much from the log. But did you get an idea from my problem?

    Yes, the UTM is behind a NAT router. But I think from L2TP standard it shouldn't be a problem with NAT-T. As well the UTM IPSec stack recognized the NAT and therefore say: "NAT-Traversal: Result using RFC 3947: both are NATed".

    To exclude a problem with NAT I installed a VPN server behind the UTM firewall with same parameter as on the UTM. With that new VPN server and the clients L2TP tunnel is coming up. Is it a problem with the L2TP implementation in UTM software?

    Thanks

    Martin

  • 0 in reply to MartinBergs
    Just after establishing an ISAKMP SA and the line I cited above, you see messages about "INVALID_ID_INFORMATION." The IP on the UTM's interface is used in the calculation of the Integrity Check Value sent to the client. When the client received the message with the ICV from the public IP of the router in front of the UTM, it calculated a response that the UTM couldn't recognize.

    If the UTM were told the public IP on your router, it could calculate the ICV using that and the connection could be successful. The underlying IPsec implementation is StrongSWAN which uses a parameter called "leftid" which would allow that, but there is no selection for that in WebAdmin. One can do it from the command line by manually modifying the IPsec configuration file but that would void support for a device covered by a paid subscription.

    If your installation is in your home, then you can Google site:community.sophos.com/products/unified-threat-management/f/58 "leftid"

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob

    I'm not so familiar with StrongSwan, in fact it's my first contact. Therfore it took me quiet a long time to test.

    First I did as you recommend and edited the configuration files (ipsec.conf and ipsec.secrets) manually. In fact I tried as well editing the default files to make the changes boot save but for testing it was easier to change the non-default files.
    So I added the lines

    leftid="62.203.xxx.194" -> public IP of NAT router
    and
    62.203.xxx.194 %any : PSK 010101010101010101


    Anyway the VPN was still not successful and phase 2 still fail.
     
    2016:02:27-13:51:53 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21067 #4: cannot respond to IPsec SA request because no connection is known for 62.203.xxx.194/32===192.168.xxx.191:4500[62.203.xxx.194]:17/1701...178.197.xxx.230:21067[10.95.177.108]:17/%any==={10.95.177.108/32}
    2016:02:27-13:51:53 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21067 #4: sending encrypted notification INVALID_ID_INFORMATION to 178.197.xxx.230:21067

    This is the output of ipsec status
    dcfw220:/var/sec/chroot-ipsec/etc # ipsec status
    000 "L_REF_IpsL2tForMartinr_0": 192.168.xxx.191[62.203.xxx.194]:17/1701...%any[%any]:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
    000 "L_REF_IpsL2tForMartinr_0":   newest ISAKMP SA: #0; newest IPsec SA: #0;
    000 "L_REF_IpsL2tForMartinr_1": 192.168.xxx.191[62.203.xxx.194]:17/0...%any[%any]:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
    000 "L_REF_IpsL2tForMartinr_1":   newest ISAKMP SA: #0; newest IPsec SA: #0;
    000


    Then I started reading the StrongSwan documentation and tried a lot of recommendation on the StrongSwan mailing list for similar problems and error messages.

    In the meantime I found the configuration for leftid in the Web GUI. It is hidden in Remote Access -> IPSec -> Advanced -> Preshared Key Settings. Enter a value in VPN ID will be the leftid in ipsec.conf. :-)


    Beside a lot of other stuff I tried the option leftsubnet which look for me most promising. Now I get a new different error message.

    I added the lines

    leftid="62.203.xxx.194" -> public IP of NAT router (lines auto added by GUI, see above)
    leftsubnet="62.203.xxx.194/32" -> public IP of NAT router
    and
    62.203.xxx.194 %any : PSK 010101010101010101 (lines auto added by GUI, see above)

    ipsec.log
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: received Vendor ID payload [RFC 3947]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: ignoring Vendor ID payload [FRAGMENTATION 80000000]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: packet from 178.197.xxx.230:45901: received Vendor ID payload [Dead Peer Detection]
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[1] 178.197.xxx.230:45901 #5: responding to Main Mode from unknown peer 178.197.xxx.230:45901
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[1] 178.197.xxx.230:45901 #5: NAT-Traversal: Result using RFC 3947: both are NATed
    2016:02:27-14:07:17 dcfw220 pluto[28914]: | NAT-T: new mapping 178.197.xxx.230:45901/21072)
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[1] 178.197.xxx.230:21072 #5: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[1] 178.197.xxx.230:21072 #5: Peer ID is ID_IPV4_ADDR: '10.95.177.108'
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072 #5: deleting connection "L_REF_IpsL2tForMartinr_1"[1] instance with peer 178.197.xxx.230 {isakmp=#0/ipsec=#0}
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072 #5: Dead Peer Detection (RFC 3706) enabled
    2016:02:27-14:07:17 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072 #5: sent MR3, ISAKMP SA established
    2016:02:27-14:07:18 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_0"[1] 178.197.xxx.230:21072 #6: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
    2016:02:27-14:07:18 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_0"[1] 178.197.xxx.230:21072 #6: responding to Quick Mode
    2016:02:27-14:07:18 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072 #5: ignoring informational payload, type INVALID_HASH_INFORMATION
    2016:02:27-14:07:18 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072 #5: received Delete SA payload: deleting ISAKMP State #5
    2016:02:27-14:07:18 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072 #5: deleting connection "L_REF_IpsL2tForMartinr_0"[1] instance with peer 178.197.xxx.230 {isakmp=#0/ipsec=#0}
    2016:02:27-14:07:18 dcfw220 pluto[28914]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21072: deleting connection "L_REF_IpsL2tForMartinr_1"[2] instance with peer 178.197.xxx.230 {isakmp=#0/ipsec=#0}
    2016:02:27-14:07:18 dcfw220 pluto[28914]: ERROR: asynchronous network error report on br0 for message to 178.197.xxx.230 port 21072, complainant 178.197.xxx.230: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]




    dcfw220:/var/sec/chroot-ipsec/etc # ipsec status
    000 "L_REF_IpsL2tForMartinr_0": 62.203.xxx.194/32===192.168..xxx.191[62.203.xxx.194]:17/1701...%any[%any]:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
    000 "L_REF_IpsL2tForMartinr_0":   newest ISAKMP SA: #0; newest IPsec SA: #0;
    000 "L_REF_IpsL2tForMartinr_1": 62.203.xxx.194/32===192.168..xxx.191[62.203.xxx.194]:17/0...%any[%any]:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
    000 "L_REF_IpsL2tForMartinr_1":   newest ISAKMP SA: #0; newest IPsec SA: #0;
    000


    So far I have no idea why phase 2 still fail but I keep on digging.
    If you or anyone have a hint please post here.

    Thanks
    Martin

  • 0 in reply to MartinBergs

    In fact,  I was thinking about the site to site implementation, I don't know if the leftid setting is considered in the L2TP/IPSec  implementation. I think I would use the SSL VPN instead.

    EDIT 2016-04-04: I believe that the leftid now can be set in the 'VPN ID' field on the 'Advanced' tab of 'IPsec' for PSK tunnels.  If someone tries that and confirms that this problem is solved by using the real public IP there instead of the private IP on the External interface, please respond to this thread,

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob


    Finally I gave up and decided not to implement the remote access VPN with L2TP over IPsec or Cisco VPN Client.

    I tried with clients using iOS , Mac OS X, Windows and Android but I was always unable to establish a VPN connection with L2TP over IPSec.

    The connection stopped when the quick mode was going to be started and these have been the last lines from the ipsec.log

    #10: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
    #10: responding to Quick Mode
    #9: ignoring informational payload, type INVALID_HASH_INFORMATION
    #9: received Delete SA payload: deleting ISAKMP State #9
    #9: deleting connection "L_REF_IpsL2tForMartinr_0"[4] instance with peer 178.197.xxx.230 {isakmp=#0/ipsec=#0}

    As my Sophos UTM is nated behind the internet router and has no public IP configuration on the WAN interface I guess Sophos UTM and the strongSwan implementation used in Sophos UTM is unable to handle this situation.


    I tried Cisco VPN Client as well. With iOS it was working out of the box but OS X had a problem. It just stopped during main mode

    #15: responding to Main Mode from unknown peer 62.203.xxx.194:1879
#15: NAT-Traversal: Result using RFC 3947: both are NATed

    As I became tired from searching for a way L2TP over IPSec to use for remote Access VPN I decided to use an IPSec SSL VPN instead (as you said).

    And this solution was working on all my clients right from beginning. The only disadvantage from using SSL VPN for remote access is that you need to install an additional application on the clients as iOS, OS X and Windows have only L2TP and Cisco IPSec support on board by default.

    Cheers Martin

  • 0 in reply to BAlfson

    I made a note on the "answer" post that it's now possible to set the leftid.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob

    I already tried the 'VPN ID' field on the 'Advanced' tab of 'IPsec' for PSK tunnels with L2TP over IPSec. It wasn't successful for this kind of remote access and NATed firewall WAN IP.

    Before setting the 'VPN ID' field

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: sent MR3, ISAKMP SA established

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: cannot respond to IPsec SA request because no connection is known for 62.203.xxx.194/32===192.168.xxx.191:4500[192.168.xxx.191]:17/1701...178.197.xxx.234:21318[10.120.xxx.29]:17/%any==={10.120.xxx.29/32}

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: sending encrypted notification INVALID_ID_INFORMATION to 178.197.xxx.234:21318

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x95b3c836 (perhaps this is a duplicated packet)

    After setting the 'VPN ID' field

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21995 #1: sent MR3, ISAKMP SA established

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_0"[1] 178.197.xxx.230:21995 #2: NAT-Traversal: received 2 NAT-OA. using first, ignoring others

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_0"[1] 178.197.xxx.230:21995 #2: responding to Quick Mode

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21995 #1: ignoring informational payload, type INVALID_HASH_INFORMATION

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21995 #1: received Delete SA payload: deleting ISAKMP State #1

    Cheers

    Martin

Reply
  • 0 in reply to BAlfson

    Hi Bob

    I already tried the 'VPN ID' field on the 'Advanced' tab of 'IPsec' for PSK tunnels with L2TP over IPSec. It wasn't successful for this kind of remote access and NATed firewall WAN IP.

    Before setting the 'VPN ID' field

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: sent MR3, ISAKMP SA established

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: cannot respond to IPsec SA request because no connection is known for 62.203.xxx.194/32===192.168.xxx.191:4500[192.168.xxx.191]:17/1701...178.197.xxx.234:21318[10.120.xxx.29]:17/%any==={10.120.xxx.29/32}

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: sending encrypted notification INVALID_ID_INFORMATION to 178.197.xxx.234:21318

    dcfw220 pluto[11665]: "L_REF_IpsL2tForMartinr_1"[12] 178.197.xxx.234:21318 #6: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x95b3c836 (perhaps this is a duplicated packet)

    After setting the 'VPN ID' field

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21995 #1: sent MR3, ISAKMP SA established

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_0"[1] 178.197.xxx.230:21995 #2: NAT-Traversal: received 2 NAT-OA. using first, ignoring others

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_0"[1] 178.197.xxx.230:21995 #2: responding to Quick Mode

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21995 #1: ignoring informational payload, type INVALID_HASH_INFORMATION

    dcfw220 pluto[19551]: "L_REF_IpsL2tForMartinr_1"[2] 178.197.xxx.230:21995 #1: received Delete SA payload: deleting ISAKMP State #1

    Cheers

    Martin

Children
No Data
Unfiltered HTML