Remote access behind NAT router

do you forward all incoming packets from NAt-Router to utm?

I use ipsec and SSL-VPN with this scenario. There is no special configuration.

which NAT Router do you use?

check firewall-live-log while trying to build connection.

check vpn-live.log while trying to build connection.

someting to see?

Yes - all traffic forwarded to the UTM, with a TP-Link DSL router.

I've looked at the logs while connecting, and most of the references I find online suggest that NAT is the problem. 

For instance, trying IPsec, I see 

Further info:

The first connection attempt after restarting the ipsec service shows:

2016:11:21-21:13:10 utm pluto[17230]: "D_Default"[2] 1.2.3.4:49809 #1: cannot respond to IPsec SA request because no connection is known for 0.0.0.0/0===192.168.1.2:4500[5.6.7.8]...1.2.3.4:49809[10.3.77.39]===10.242.4.1/32
2016:11:21-21:13:10 utm pluto[17230]: "D_Default"[2] 1.2.3.4:49809 #1: sending encrypted notification INVALID_ID_INFORMATION to 1.2.3.4:49809

Subsequent attempts get the duplicate message message.

Hi Phil, 

First, settle on one VPN connection. If you select L2TP over IPSec then, make sure UDP ports 500, 1701 and 4500 are open towards the UTM for the port communication.

Take SSH to UTM and capture the output of TCPDUMP over the specified port while trying to establish a connection with UTM. Also check the firewall log if anything is logged and dropped.

Thanks

Thanks for the pointers.

Here goes:

I'll stick with L2TP!

There's no port filtering between the internet and the UTM's outside interface. Tcpdump shows a conversation on port 500 and on 4500. No 1701 traffic - but a port scan shows it reaches the UTM if it's sent.

The firewall shows no traffic being blocked from the client's IP address.

Here's an anonymised ipsec log:

Hi, Phil, and welcome to the UTM Community!

I approved your post and then deleted the log file that likely tripped the automatic spam filter.  Please permanently disable debug in IPsec.  In ten years here, I've not seen a single issue resolved by having debug on.

Start the IPsec Live Log.  Once it's displayed the last 10 lines, attempt a connection with IPsec and then show us the result for a single attempt.  That should be 50 or 60 lines.

Cheers - Bob

Thanks Bob

There's me thinking debug would help...

Here's the log with debug disabled.

2016:11:22-20:34:35 utm pluto[14342]: adding interface eth0/eth0 192.168.70.254:500
2016:11:22-20:34:35 utm pluto[14342]: adding interface eth0/eth0 192.168.70.254:4500
2016:11:22-20:34:35 utm pluto[14342]: adding interface lo/lo 127.0.0.1:500
2016:11:22-20:34:35 utm pluto[14342]: adding interface lo/lo 127.0.0.1:4500
2016:11:22-20:34:35 utm pluto[14342]: adding interface lo/lo ::1:500
2016:11:22-20:34:35 utm pluto[14342]: loading secrets from "/etc/ipsec.secrets"
2016:11:22-20:34:35 utm pluto[14342]: loaded PSK secret for <MY PUBLIC IP ADDRESS> %any
2016:11:22-20:34:35 utm pluto[14342]: listening for IKE messages
2016:11:22-20:34:35 utm pluto[14342]: added connection description "L_for user"
2016:11:22-20:34:35 utm pluto[14342]: added connection description "L_for user"
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: received Vendor ID payload [RFC 3947]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2016:11:22-20:36:20 utm pluto[14342]: packet from <REMOTE IP ADDRESS>:627: received Vendor ID payload [Dead Peer Detection]
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[1] <REMOTE IP ADDRESS>:627 #1: responding to Main Mode from unknown peer <REMOTE IP ADDRESS>:627
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[1] <REMOTE IP ADDRESS>:627 #1: NAT-Traversal: Result using RFC 3947: both are NATed
2016:11:22-20:36:20 utm pluto[14342]: | NAT-T: new mapping <REMOTE IP ADDRESS>:627/64916)
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[1] <REMOTE IP ADDRESS>:64916 #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[1] <REMOTE IP ADDRESS>:64916 #1: Peer ID is ID_IPV4_ADDR: '10.0.196.138'
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: deleting connection "L_for user"[1] instance with peer <REMOTE IP ADDRESS> {isakmp=#0/ipsec=#0}
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Dead Peer Detection (RFC 3706) enabled
2016:11:22-20:36:20 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sent MR3, ISAKMP SA established
2016:11:22-20:36:25 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: cannot respond to IPsec SA request because no connection is known for <MY PUBLIC IP ADDRESS>/32===192.168.1.2:4500[<MY PUBLIC IP ADDRESS>]:17/1701...<REMOTE IP ADDRESS>:64916[10.0.196.138]:17/%any==={10.0.196.138/32}
2016:11:22-20:36:25 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_ID_INFORMATION to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:28 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:28 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:31 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:31 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:34 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:34 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:38 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:38 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:41 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:41 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:45 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:45 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:48 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:48 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:51 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x87e63834 (perhaps this is a duplicated packet)
2016:11:22-20:36:51 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sending encrypted notification INVALID_MESSAGE_ID to <REMOTE IP ADDRESS>:64916
2016:11:22-20:36:51 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: received Delete SA payload: deleting ISAKMP State #1
2016:11:22-20:36:51 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916: deleting connection "L_for user"[2] instance with peer <REMOTE IP ADDRESS> {isakmp=#0/ipsec=#0}

Here are the key lines:

016:11:22-20:36:20 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: sent MR3, ISAKMP SA established
2016:11:22-20:36:25 utm pluto[14342]: "L_for user"[2] <REMOTE IP ADDRESS>:64916 #1: cannot respond to IPsec SA request because no connection is known for <MY PUBLIC IP ADDRESS>/32===192.168.1.2:4500[<MY PUBLIC IP ADDRESS>]:17/1701...<REMOTE IP ADDRESS>:64916[10.0.196.138]:17/%any==={10.0.196.138/32}

We see that the connection fails right after the ISAKMP SA is established.  There are three possibilities:

1. The PSK isn't correct.
2. (maybe 1.b) There was already a "Respond Only" IPsec Remote Gateway defined in Site-to-Site and you didn't select 'Enable probing of preshared keys' on the 'Advanced' tab of 'IPsec'.  One would need to re-enter the L2TP PSK after selecting that.
3. The UTM is behind a NAT'ing router - it doesn't have a public IP on the External interface.  This "breaks" IPsec.

I rarely read the title of a thread.  Had I done so, I would have saved us both a lot of effort. [;)]

The best would be to put your modem/router in bridge mode so that you can get a public IP on the External interface - that pays off in several ways.  My preference in any case would be to use the SSL VPN which can work either way.  The free OpenVPN apps for iPhone and Android are my preference. The UTM Client works great on Windows platforms.

Cheers - Bob

Ah...

The PSK's definitely right... and there is indeed a gateway set up in site-to-site (so probing is already enabled)... so my vote goes with 3!

(As my old maths teacher used to say "The answer's in the question" :-) )

I'll switch to trying SSL.

Thanks for your speedy response.

You're welcome, Phil.  Wait a minute, would you try something?  Sophos recently added what I believe may be the missing "leftid" for StrongSWAN.  In 'Preshared Key Settings' on the 'Advanced' tab, put the Public IP of the modem in 'VPN ID' - does L2TP/IPsec work then?

Cheers - Bob