strongSwan

Just to make sure I understand it right, if I specify mode = pass, does that mean when the packets sent by the clients match the traffic selector, they are tunneled to the server with IP in IP fashion, but without ESP or AH applied?

Thanks for the reply, Tobias.

I used the following config on the server according to your suggestions, and it worked, but was opposite to what I was expecting.

connections {
    vpn {
        version = 2
        pools = vpn
        proposals = aes128gcm16-prfsha256-ecp256,chacha20poly1305-prfsha256-curve25519
        local {
            id = vpn
            auth = psk
        }
        children {
            child {
                local_ts = 0.0.0.0/0
                ipcomp = yes
                esp_proposals = aes128gcm16-prfsha256-ecp256,chacha20poly1305-prfsha256-curve25519
                hw_offload = auto
            }
        }
    }
    passthrough-88 {
        remote_addrs = 127.0.0.1
        children {
            passthrough-88 {
                local_ts = 8.8.8.8[17/53]
                remote_ts = 0.0.0.0/0
                mode = pass
                start_action = trap
            }
        }
    }
    drop-84 {
        remote_addrs = 127.0.0.1
        children {
            drop-84 {
                local_ts = 8.8.4.4[17/53]
                remote_ts = 0.0.0.0/0
                mode = drop
                start_action = trap
            }
        }
    }
}

The client is able to receive DNS responses from 8.8.4.4, but not 8.8.8.8. I wonder why that's the case?

tcpdump on the server says that server sents the DNS request to 8.8.8.8, but unlike 8.8.4.4, it never gets any responses. Removing connection passthrough-88 and restarting charon, both 8.8.8.8 and 8.8.4.4 work.

I initially thought pass policies on the server made the client send matching packets without having ipsec applied, but after checking wireshark, it seems that's not the case, client's DNS requests are still encapsulated in ESP and are tunneled.

I'd appreciate it if you could keep enlighting me a little bit. I have three questions:

1. Why with the previous config, 8.8.8.8 response is dropped but not 8.8.4.4?
2. Why client's 8.8.8.8 DNS requests still go through IPsec? Also, wireshark says client's ssh connection to server doesn't go through IPsec with the previous config. Without a pass ssh policy on the server, why that's the case? The client is a mac, and from the IKE_AUTH exchange, it says the mac use 0.0.0.0 - 255.255.255.255 for both TSi and TSr, so ts should ultimately be controlled by the server.
3. Should child SAs in the previous config be in different connections or all in connection vpn's children section? I gave them their own connection because otherwise I couldn't specified remote_addrs = 127.0.0.1 as suggested. But I tried merging child SAs, and both 8.8.8.8 and 8.8.4.4 didn't respond (but tcpdump on the server said requests were sent)

I guess this starts to look like mailing list material? Let me know if it's ok to ask them here.

I initially thought pass policies on the server made the client send matching packets without having ipsec applied, but after checking wireshark, it seems that's not the case, client's DNS requests are still encapsulated in ESP and are tunneled.

IPsec policies are always local. Configured shunt policies (passthrough/drop) on the server have no effects on the policies installed on the client. However, they will affect how traffic is handled on the server (the policies are applied only there).

1. Why with the previous config, 8.8.8.8 response is dropped but not 8.8.4.4?

It might have been processed as is (i.e. forwarded as plaintext) as the passthrough policy prevented applying the actual IPsec policy/SA. The drop policy should have a similar effect, though. You can check the installed policies (and whether they were used) with ip -s xfrm policy.

2. Why client's 8.8.8.8 DNS requests still go through IPsec? Also, wireshark says client's ssh connection to server doesn't go through IPsec with the previous config. Without a pass ssh policy on the server, why that's the case? The client is a mac, and from the IKE_AUTH exchange, it says the mac use 0.0.0.0 - 255.255.255.255 for both TSi and TSr, so ts should ultimately be controlled by the server.

As said, policies on the server don't influence policies on the client. The SSH issue is because macOS doesn't send traffic to the VPN server's IP address through the tunnel (that's a similar local policy/routing decision), you'd have to connect to an internal/second IP address of the server to reach it via VPN. Any client is completely free to ignore the traffic selectors and tunnel less traffic (or even more, however, that will be dropped by policies on the server). For instance, Windows never tunnels traffic for the local subnet via VPN.

3. Should child SAs in the previous config be in different connections or all in connection vpn's children section? I gave them their own connection because otherwise I couldn't specified remote_addrs = 127.0.0.1 as suggested. But I tried merging child SAs, and both 8.8.8.8 and 8.8.4.4 didn't respond (but tcpdump on the server said requests were sent)

You definitely want to use a separate connection section for the shunts, but merging these should work (e.g. adding the drop-84 child section to the children section of passthrough-88).

Thanks for the detailed explanation Tobias,

I corrected my config, and put the ssh passthrough connection on the client. From the tcpdump on the router, it shows the ssh connect now connects directly, but there is a problem.

conntrack on the server said

tcp      6 58 SYN_RECV src=10.0.0.1 dst=1.1.1.1 sport=53526 dport=22 packets=1 bytes=60 src=1.1.1.1 dst=2.2.2.2 sport=22 dport=53526 packets=2 bytes=120 mark=0 use=1

where 10.0.0.1 was the IP address the client had inside the tunnel, so when the ssh response came back, it got NAT to 10.0.0.1, which the router didn't recognize and was dropped.

my passthrough connection on the client is like this

connections {
    vpn {
        version = 2
        remote_addrs = 1.1.1.1
        proposals = aes128gcm16-prfsha256-curve25519
        vips = 0.0.0.0
        local {
            auth = psk
        }
        remote {
            id = vpn
            auth = psk
        }
        children {
            child {
                remote_ts = 0.0.0.0/0
                ipcomp = yes
                esp_proposals = aes128gcm16-esn
                hw_offload = auto
                start_action = start
            }
        }
    }
    pass {
        remote_addrs = 127.0.0.1
        children {
            pass {
                local_ts  = 0.0.0.0/0[tcp]
                remote_ts = 0.0.0.0/0[tcp/ssh]
                mode = pass
                start_action = trap
            }
        }
    }
}

and why the pass policy makes the strongswan client send packets with ip inside tunnel as src ip?

Passthrough policies based on protocols/ports can't be combined with virtual IPs, which use special routes in table 220 to force the virtual IPs as source address, if the same remote IPs are covered. No routes, to avoid such an address selection, are installed for policies with protocol/port selector, because routes are based on addresses not protocol/port.