Hi, I have raised a similar issue before and I would like to request help on this again as I cannot figure this out.
Using VyOS 1.2.3 AMI on AWS. I have been told by AWS and I believe that it is accurate to state that an EIP assigned to an instance (in this case a VyOS AMI) is NOT considered a NAT. However, it looks like according to the logs, VyOS / Strongswan clearly thinks that it is behind a NAT and thus IPSec is established over port 4500. I do not want to use port 4500 but rather port 500 / ESP. Is anyone experiencing a similar issue and is there a way around it? I can replicate this issue by establishing tunnels to multiple different environments (GCP, Azure etc.).
IP 52.215 is local (VyOS)
IP 35.242 is remote side
The authentication id is correctly set to the public IP of the VyOS instance in the config. Does anyone have any ideas how to get around this NAT detection issue and get IPSec not to use port 4500?
Hi, the far side in this instance is Google Cloud’s IPSec. Local config as follows:
set vpn ipsec esp-group GCP compression ‘disable’
set vpn ipsec esp-group GCP lifetime ‘27000’
set vpn ipsec esp-group GCP mode ‘tunnel’
set vpn ipsec esp-group GCP pfs ‘enable’
set vpn ipsec esp-group GCP proposal 1 encryption ‘aes128’
set vpn ipsec esp-group GCP proposal 1 hash ‘sha1’
set vpn ipsec ike-group GCP dead-peer-detection action ‘restart’
set vpn ipsec ike-group GCP dead-peer-detection interval ‘15’
set vpn ipsec ike-group GCP dead-peer-detection timeout ‘30’
set vpn ipsec ike-group GCP ikev2-reauth ‘no’
set vpn ipsec ike-group GCP key-exchange ‘ikev2’
set vpn ipsec ike-group GCP lifetime ‘28800’
set vpn ipsec ike-group GCP mobike ‘disable’
set vpn ipsec ike-group GCP proposal 1 dh-group ‘14’
set vpn ipsec ike-group GCP proposal 1 encryption ‘aes128’
set vpn ipsec ike-group GCP proposal 1 hash ‘sha1’
set vpn ipsec ipsec-interfaces interface ‘eth0’
set vpn ipsec logging log-level ‘1’
set vpn ipsec site-to-site peer 35.242.xxx.xxx authentication id ‘52.215.xxx.xxx’
set vpn ipsec site-to-site peer 35.242.xxx.xxx authentication mode ‘pre-shared-secret’
set vpn ipsec site-to-site peer 35.242.xxx.xxx authentication pre-shared-secret xxxxxx
set vpn ipsec site-to-site peer 35.242.xxx.xxx connection-type ‘initiate’
set vpn ipsec site-to-site peer 35.242.xxx.xxx ike-group ‘GCP’
set vpn ipsec site-to-site peer 35.242.xxx.xxx ikev2-reauth ‘inherit’
set vpn ipsec site-to-site peer 35.242.xxx.xxx local-address ‘172.16.2.24’
set vpn ipsec site-to-site peer 35.242.xxx.xxx vti bind ‘vti2’
set vpn ipsec site-to-site peer 35.242.xxx.xxx vti esp-group ‘GCP’
The tunnel is up and traffic is traversing the tunnel but on UDP 4500. Disabling mobike as per NAT Traversal :: strongSwan Documentation does not seem to make a difference.
Thanks. But this is not the behavior with the VyOS 1.8 AMI. The EIP is assigned in the same manner to the AMI - and tunnel established to GCP over UDP 500. So then this would mean its due to functionality in the later version of Strongswan that is different?
Before strongSwan 5.0.0, NAT discovery and traversal for IKEv1 had to be enabled by setting nat_traversal=yes in the config setup section of ipsec.conf. Otherwise, strongSwan 4.x’s IKEv1 pluto daemon would not accept incoming IKE packets with a UDP source port different from 500. Since 5.0.0 IKEv1 traffic is handled by the charon daemon, which supports NAT traversal according to RFC 3947 (and some of its early drafts) without having to enable it explicitly (it can’t be disabled either, though).
Hello, @avdvyver!
Using UDP/4500 is not equal to NAT traversal. IKEv2 protocol allows using 4500 port regardless of NAT and many implementations doing this by default. So, if everything works, you don’t need to worry about this.
Thank you - but its a matter of understanding why the behavior is different from the previous version of VyOS / Strongswan instead of not worrying about it because it works.
