Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

> On Mar 29, 2018, at 5:46 AM, Tobias Brunner wrote: > > Hi Rich, > >> Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET] >> sending packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes) >> Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET]

Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

Hi Rich, > Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET] sending > packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes) > Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET] > received packet: from 13.88.23.150[1031] to 172.17.128.86[500]

Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

Hi Tobias and list, I was able to duplicate my issues around NAT remapping in Azure with StrongSwan at both ends, so now Racoon is completely out of the picture. I captured some more detailed logs of the situation. In the logs below, stg-vault-zk04 is in AWS and has static NAT in front of it

Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

Hey Tobias, Thanks for your quick response. > On Mar 23, 2018, at 1:20 PM, Tobias Brunner wrote: > > Hi Rich, > >> 1. IKE and ESP SAs are established normally with NAT-T, i.e. 500:4500. >> 2. NAT remapping occurs within Azure, at which point StrongSwan sees IKE >>

Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

Hi Rich, > 1. IKE and ESP SAs are established normally with NAT-T, i.e. 500:4500. > 2. NAT remapping occurs within Azure, at which point StrongSwan sees IKE > packets come from port 1027 instead of 500. (i.e. instead of 500:500 it’s > 500:1027). And what happens to port 4500? Why would there

[strongSwan] Clarifying behaviour around NAT-T and remapping

Hello again! I’m still working on getting Racoon and Strongswan talking to each other, and I’ve run into an issue with NAT remapping. The issue is primarily on the Racoon side, but I want to understand Strongswan behaviour to figure out how to move forward because Racoon is long unmaintained