strongSwan

I didn't make that choice for kernel-libipsec plugin, what am I suppose to be using?

I didn't make that choice for kernel-libipsec plugin, what am I suppose to be using?

How come you are using it then? On Linux, you probably want to use the kernel-netlink plugin.

So are you saying SS the install makes kernel-libipsec plugin the default, and instead I need to change that in the ipsec.conf like the Host-to-Host Tunnels section indicates?

So are you saying SS the install makes kernel-libipsec plugin the default

It's definitely not the default (see e.g. Autoconf or PluginList).

and instead I need to change that in the ipsec.conf like the Host-to-Host Tunnels section indicates?

Sorry, no idea what you are referring to. But if you wonder how to enable/disable plugins, see PluginLoad.

Uninstalled kernel-libipsec plugin and encapsulation error has disappeared, Phase 2 has come up. We still cannot route any traffic into tunnel, it keeps going to SS default gateway. We are trying to do Source NATing and have tried many combinations with no luck.
Any advice or do you need more details?

Any advice or do you need more details?

Definitely need more details to provide any specific advice. Generally, just make sure the negotiated IPsec policies match the actual traffic (i.e. after the SNAT).

I've attached the 6 configs (excluding secrets) we've modified in their current state of many, and a diagram. We are currently using a test server 10.0.56.157 instead of the two production servers in the diagram to route traffic into the tunnel. Hope this helps clarify what we're trying to do.

ipsec statusall?

This version doesn't support ipsec statusall.

Then it's probably strongswan statusall.

Heres systemctl status strongswan

Why would you think that helps?

Please run that again after the connection is up.

Updated strongswan statusall after systemctl restart strongswan

Looks fine (except for the horrible algorithms and protocol version). So if your packets come from 7.7.20.5 (after the SNAT) and are addressed to 158.73.182.48, they should get tunneled.

Here is the strongswan.conf that it says "no files found matching '/etc/strongswan/strongswan.conf'". This is after editing trying to NOT use kernel-libipsec so I need to go back an clean it up since we just removed the kernel-libipsec plugin.

That's because your NAT rule is incorrect. You used -d instead of -s.

Is there a command to see if there are packets going into the tunnel? The remote side doesn't have a test server like me so they won't respond to my connection attempts like normal.

This what my iptables looks like now.

[tjung@ip-10-0-58-73 ~]$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- ip-10-0-56-157.ec2.internal anywhere to:7.7.20.5

Is there a command to see if there are packets going into the tunnel?

statusall shows the packet/byte counters and for iptables you can use -v to see counters for each rule. You should also see outbound ESP packets in tcpdump.

I never see ESP packets in my tcpdump (example attached earlier). While I see my pkts count go up when pinging from test server, remote end ASA says they never see packets in the tunnel.

Chain POSTROUTING (policy ACCEPT 867 packets, 64852 bytes)
pkts bytes target prot opt in out source destination
5 396 SNAT all -- any any ip-10-0-56-157.ec2.internal anywhere to:7.7.20.5

I never see ESP packets in my tcpdump (example attached earlier)

Obviously, as the NAT rule was wrong. If it is correct now, i.e. the packets' addresses match the IPsec policy, you should see some.

While I see my pkts count go up when pinging from test server, remote end ASA says they never see packets in the tunnel.

Chain POSTROUTING (policy ACCEPT 867 packets, 64852 bytes)
pkts bytes target prot opt in out source destination
5 396 SNAT all -- any any ip-10-0-56-157.ec2.internal anywhere to:7.7.20.5

That's only the NAT rule. What about the packet counters for the IPsec SAs?

Remote end ASA still says they never see packets.

Maybe ESP is blocked by a firewall between the two hosts. You could try forcing UDP encapsulation via forceencaps=yes.

We're not using the firewall, but in the etc-strongswan-ipsec.conf.txt from earlier you'll see we already have forceencaps=yes

We're not using the firewall

There is no firewall whatsoever between your IKE/IPsec endpoints?

but in the etc-strongswan-ipsec.conf.txt from earlier you'll see we already have forceencaps=yes

That's not reflected by the output of statusall, which says ESP and not ESP in UDP. Maybe the peer does not support NAT-Traversal (or has it disabled).

Our peer?

Our peer?

The other IKE implementation.

Here is my feedback from the remote ASA guy. NAT-Traversal is not enabled. As long as your VPN device (SS) is using a public IP address or is receiving a static NAT to a public IP address, NAT-T does not come into play.

According to this, it looks like SS is doing NAT-T just like our Fortigate is. Do you agree that NAT-T is not the problem?
IKEv1
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).

As long as your VPN device (SS) is using a public IP address or is receiving a static NAT to a public IP address, NAT-T does not come into play.

The whole point of forcing encapsulation is to use NAT-T to fake a NAT situation even if there is no NAT in order to enable UDP encapsulation.

Are you able to join a screen share troubleshooting with me and ASA guy this afternoon?

No.

Since you are sending ESP packets now, it's either a problem on the way to the other end (e.g. a firewall blocking ESP) or at the other end (could be a firewall or routing problem).

Help me understand, since uninstalling the kernel-libipsec plugin and the encapsulation error going away, the ipsec0 interface is gone (below). How does the traffic get into the tunnel then?

[tjung@ip-10-0-58-73 ~]$ sudo netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 9001 473270 0 0 0 507323 0 0 0 BMRU
lo 65536 0 0 0 0 0 0 0 0 LRU

Where are these OUT packets going?
sudo swanctl -l
out 1c938b96, 60 bytes, 1 packets, 3s ago

How does the traffic get into the tunnel then?

IPsec policies (see ip xfrm policy) that match the traffic direct them to the IPsec SAs (ip xfrm state).

Where are these OUT packets going?

They get processed by the outbound IPsec SA (the traffic counters there are actually those of that SA) and then sent as ESP packets.

How can I verify NAT traversal is actually working?

How can I verify NAT traversal is actually working?

Read the log, or check the status output (as mentioned above).

I don't think the xfrm state is correct, it has the remote ASA public but SS private IP (src 10.0.58.73 dst 139.177.139.10).
Shouldn't src be the SS public IP which is 52.86.64.169?

Depends on the IP addresses and routes on your system and the strongSwan config.

I had my remote ASA guy run a Pcap (attached), it’s all ISAKMP, he never sees any ESP packets.

So try to find out where the ESP packets are dropped.