Site-To-Site IPSEC VPN

I was able to somewhat resolve the issue, I found that port 500 was being forwarded for use by an old VPN. Once I disabled the port forward, each gateway was able to complete the phase 1 authentication.

I am now however getting an error:

[HTML]racoon: ERROR: pfkey DELETE received: ESP [500]->[500] spi=234491392(0xdfa0e00) [/HTML]

Again, any help is appreciated.

Cheers,
Anthony

Hi, Anthony, and welcome to the User BB!

You're the first person to mention raccoon here since the forum was established. [;)]  I don't think we'll find anyone with experience connecting to it.  That said, let's take a look at the UTM's IPsec log for a single connection attempt.  Please make sure debug is off and show us about 50 lines.

Also, can you confirm that NAT-T and DPD are selected on both sides?

Cheers - Bob
PS Is there a reason to use 3DES instead of a faster, more-secure new policy like AES 128 PFS?

Hi Bob,

Thanks for your reply. Hopefully it's an issue which can be resolved similar to issues with other VPN solutions... it seems Racoon is the software which TP-Link like to have on their modems / routers.

Here's a snapshot of the IPSEC VPN Log from the UTM:
[HTML]
2014:08:20-11:31:39 HHGW ipsec_starter[31316]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
2014:08:20-11:31:39 HHGW pluto[31328]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
2014:08:20-11:31:39 HHGW pluto[31328]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve
2014:08:20-11:31:39 HHGW pluto[31328]: including NAT-Traversal patch (Version 0.6c)
2014:08:20-11:31:39 HHGW pluto[31328]: Using Linux 2.6 IPsec interface code
2014:08:20-11:31:39 HHGW ipsec_starter[31322]: pluto (31328) started after 20 ms
2014:08:20-11:31:39 HHGW pluto[31328]: loading ca certificates from '/etc/ipsec.d/cacerts'
2014:08:20-11:31:39 HHGW pluto[31328]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
2014:08:20-11:31:39 HHGW pluto[31328]: loading aa certificates from '/etc/ipsec.d/aacerts'
2014:08:20-11:31:39 HHGW pluto[31328]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2014:08:20-11:31:39 HHGW pluto[31328]: Changing to directory '/etc/ipsec.d/crls'
2014:08:20-11:31:39 HHGW pluto[31328]: loading attribute certificates from '/etc/ipsec.d/acerts'
2014:08:20-11:31:39 HHGW pluto[31328]: listening for IKE messages
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface eth1/eth1 10.0.0.4:500
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface eth1/eth1 10.0.0.4:4500
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface eth0/eth0 192.168.0.1:500
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface eth0/eth0 192.168.0.1:4500
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface lo/lo 127.0.0.1:500
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface lo/lo 127.0.0.1:4500
2014:08:20-11:31:39 HHGW pluto[31328]: adding interface lo/lo ::1:500
2014:08:20-11:31:39 HHGW pluto[31328]: loading secrets from "/etc/ipsec.secrets"
2014:08:20-11:31:39 HHGW pluto[31328]: loaded PSK secret for 10.0.0.4 110.142.xx.***
2014:08:20-11:31:39 HHGW pluto[31328]: added connection description "S_MPACC"
2014:08:20-11:31:39 HHGW pluto[31328]: "S_MPACC" #1: initiating Main Mode
2014:08:20-11:31:39 HHGW pluto[31328]: ERROR: "S_MPACC" #1: sendto on eth1 to 110.142.xx.***:500 failed in main_outI1. Errno 1: Operation not permitted
2014:08:20-11:31:39 HHGW pluto[31328]: added connection description "X_MPACC"
2014:08:20-11:31:39 HHGW pluto[31328]: added connection description "X_MPACC"
2014:08:20-11:31:49 HHGW pluto[31328]: "S_MPACC" #1: received Vendor ID payload [Dead Peer Detection]
2014:08:20-11:31:50 HHGW pluto[31328]: "S_MPACC" #1: Peer ID is ID_IPV4_ADDR: '110.142.xx.***'
2014:08:20-11:31:50 HHGW pluto[31328]: "S_MPACC" #1: Dead Peer Detection (RFC 3706) enabled
2014:08:20-11:31:50 HHGW pluto[31328]: "S_MPACC" #1: ISAKMP SA established
2014:08:20-11:31:50 HHGW pluto[31328]: "S_MPACC" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
2014:08:20-11:31:51 HHGW pluto[31328]: "S_MPACC" #2: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:32:00 HHGW pluto[31328]: "S_MPACC" #2: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:32:20 HHGW pluto[31328]: "S_MPACC" #2: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:33:00 HHGW pluto[31328]: "S_MPACC" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2014:08:20-11:33:00 HHGW pluto[31328]: "S_MPACC" #2: starting keying attempt 2 of an unlimited number
2014:08:20-11:33:00 HHGW pluto[31328]: "S_MPACC" #3: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #2 {using isakmp#1}
2014:08:20-11:33:01 HHGW pluto[31328]: "S_MPACC" #3: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:33:10 HHGW pluto[31328]: "S_MPACC" #3: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:33:11 HHGW pluto[31328]: "S_MPACC" #3: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:33:31 HHGW pluto[31328]: "S_MPACC" #3: cannot route -- route already in use for "X_MPACC"
2014:08:20-11:34:10 HHGW pluto[31328]: "S_MPACC" #3: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2014:08:20-11:34:10 HHGW pluto[31328]: "S_MPACC" #3: starting keying attempt 3 of an unlimited number
2014:08:20-11:34:10 HHGW pluto[31328]: "S_MPACC" #4: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #3 {using isakmp#1}
2014:08:20-11:34:11 HHGW pluto[31328]: "S_MPACC" #4: cannot route -- route already in use for "X_MPACC"
[/HTML]

Hi, Anthony, and welcome to the User BB!
Also, can you confirm that NAT-T and DPD are selected on both sides?

DPD definitely enabled on both sides, NAT-T enabled in UTM and from experience NAT-T is automatically enabled for the TP-Links when an IPSEC tunnel is enabled as there's no setting as such in the interface.

PS Is there a reason to use 3DES instead of a faster, more-secure new policy like AES 128 PFS?

Primarily due to the TP-link default connection settings, and as part of my troubleshooting i've gone back to that to ensure that it's not a compatibility issue. When I get the VPN working I will likely change to AES.

Cheers,
Anthony

Racoon is the software which TP-Link like to have on their modems / routers.

I've since learned that it's also used in smart phones, Anthony.

sendto on eth1 to 110.142.xx.***:500 failed in main_outI1

Are you behind a device that blocks that port - or does the device itself do so?

Cheers - Bob

I've since learned that it's also used in smart phones, Anthony.

Well you learn something new every day [:)]

Are you behind a device that blocks that port - or does the device itself do so?

I don't believe that anything should be blocking it. I would have thought that by ticking the "Automatic Firewall Rule" box should allow UTM to use the port.

I will create a manual exception for UDP 500 and see how we go.

Cheers,
Anthony

I've created a manual exception in the UTM firewall to allow UDP 500 from any host to any host from any port to 500 as well as from 500 to any port.

I am however still receiving the same error in relation to SendTo on eth1 "operation not permitted"

Cheers,
Anthony

I will create a manual exception for UDP 500 and see how we go.

I was concerned about it being blocked after leaving the UTM, but I see now that that was the first line after initiating Main Mode, so it's likely that both sides are expecting messages to be signed by a different IP.  I can't tell from the above if one or both endpoints have private IPs.  IPsec doesn't play easily behind NATting routers.

If SiteB is an endpoint at 10.1.1.1, then, in your Remote Gateway definition for SiteB, you need 'VPN ID type: IP Address' and 'VPN ID (Optional): 10.1.1.1'.

If you in SiteA also have an endpoint with a NATted IP and if the TP-Link doesn't offer a similar setting as in the UTM, the easiest would be to put the TP-Link into the equivalent of "Respond only" mode.

Please post back with your results.

Cheers - Bob

so it's likely that both sides are expecting messages to be signed by a different IP.  I can't tell from the above if one or both endpoints have private IPs.  

The UTM side of the VPN does in fact have an internal IP behind a NAT, and the issue of course was that the internal IP range between the NAT and the WAN interface of the UTM was the same IP range as the endpoint LAN.

I've since changed the NAT to WAN range, set the VPN identifier and connection is UP.

Thanks very much for your help, something so obvious that I overlooked in my planning and implementation.

This is why we have testing pre-deployment!

Cheers,
Anthony