能ping通服务器同网段其他主机，但没法http访问

[shushenghong]

1、vpn server：mac os通过docker 安装，配置了ikev2 vpn分流，配置为leftsubnet=192.168.0.0/24 2、http server：是一台和vpnserver在同一个局域网的内网http服务器，ip是192.168.0.172 3、client：macos通过ikev2连接vpn，已经连接上 能ping通http server，但没法http访问http server

ping 192.168.0.172
PING 192.168.0.172 (192.168.0.172): 56 data bytes
64 bytes from 192.168.0.172: icmp_seq=0 ttl=62 time=26.445 ms
64 bytes from 192.168.0.172: icmp_seq=1 ttl=62 time=27.847 ms

curl http://192.168.0.172:8088/demo/
curl: (28) Failed to connect to 192.168.0.172 port 8088 after 75027 ms: Couldn't connect to server

4、日志为

2024-06-23T11:06:32.005870+00:00 ipsec-vpn-server pluto[618]: addconn:
2024-06-23T11:06:54.704843+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #1: proposal 1:IKE=AES_GCM_C_256-HMAC_SHA2_256-ECP_256 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256[first-match]
2024-06-23T11:06:54.713797+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #1: processed IKE_SA_INIT request from 192.168.65.1:UDP/51375 {cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=DH19}
2024-06-23T11:06:54.812945+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #1: processing decrypted IKE_AUTH request: SK{IDi,CERT,N(INITIAL_CONTACT),IDr,AUTH,CP,N(ESP_TFC_PADDING_NOT_SUPPORTED),N(NON_FIRST_FRAGMENTS_ALSO),SA,TSi,TSr,N(MOBIKE_SUPPORTED)}
2024-06-23T11:06:54.821673+00:00 ipsec-vpn-server pluto[618]: adding the CA+root cert O=IKEv2 VPN,CN=IKEv2 VPN CA
2024-06-23T11:06:54.851118+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #1: reloaded private key matching left certificate 'v******'
2024-06-23T11:06:54.852113+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #1: responder established IKE SA; authenticated peer certificate 'CN=shu, O=IKEv2 VPN' and 3072-bit PKCS#1 1.5 RSA with SHA1 signature issued by 'CN=IKEv2 VPN CA, O=IKEv2 VPN'
2024-06-23T11:06:54.865060+00:00 ipsec-vpn-server pluto[618]: pool 192.168.43.10-192.168.43.250: growing address pool from 0 to 1
2024-06-23T11:06:54.865227+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #2: proposal 1:ESP=AES_GCM_C_256-ESN:NO SPI=0d2fdbf5 chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_256;ESN=NO[first-match]
2024-06-23T11:06:54.888696+00:00 ipsec-vpn-server pluto[618]: "ikev2-cp"[1] 192.168.65.1 #2: responder established Child SA using #1; IPsec tunnel [192.168.0.0/24===192.168.43.10/32] {ESPinUDP=>0x0d2fdbf5 <0x80c9b113 xfrm=AES_GCM_16_256-NONE NATD=192.168.65.1:26615 DPD=active}

[shushenghong]

观察trafficstatus发现curl调用时inBytes outBytes确实在涨，但很慢

ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1400, outBytes=1668, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1400, outBytes=1668, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1464, outBytes=1720, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1464, outBytes=1720, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1528, outBytes=1832, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1528, outBytes=1832, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1528, outBytes=1832, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus
#2: "ikev2-cp"[1] 192.168.65.1, type=ESP, add_time=1719141577, inBytes=1592, outBytes=1884, maxBytes=2^63B, id='CN=shu, O=IKEv2 VPN', lease=192.168.43.10/32
ipsec-vpn-server:/opt/src# ipsec trafficstatus

[hwdsl2]

@shushenghong 你好！对于你的用例，你提供的日志显示 VPN 已成功连接。请检查以下项目：

1. 首先确保你的 HTTP 服务器的防火墙允许来自你运行 Docker 的 macOS 计算机的 IP 的流量，并且允许来自 VPN 客户端子网 192.168.43.0/24 的流量。检查 HTTP 服务器的监听 IP 和端口是否正确。
2. 尝试从你运行 Docker 的 macOS 计算机访问 HTTP 服务器，使用以上 curl 命令。确保从该计算机可以正常访问它。
3. 另外你可以尝试暂时移除 Docker 容器中的 IPTables FORWARD chain 的 DROP 规则来测试。首先 在容器中运行 Bash shell。然后参见： https://github.com/hwdsl2/setup-ipsec-vpn/issues/1540#issuecomment-1991865830

[shushenghong]

3. iptables -D FORWARD -j DROP 后确实可以访问了 这是啥原因呢，加上这个后会有其他问题吗？

[hwdsl2]

@shushenghong 在容器内运行 iptables -D FORWARD -j DROP 会允许所有转发的流量。这样可以达到你的用例的需求，但是会有安全风险，比如因特网上的主机可能可以访问你的 VPN 客户端的端口。

对于你的用例，在运行 iptables -D FORWARD -j DROP 后可以访问，这说明你需要在 IPTables FORWARD Chain 添加合适的防火墙规则。

如果要找到更好的解决方案的话，你可以添加一个 LOG 规则来记录被禁止的流量。

iptables -A FORWARD -j LOG

重新测试到 HTTP 服务器的连接后，使用 dmesg 命令查看 IPTables 防火墙记录。然后根据结果添加合适的 IPTables 规则。

在完成后，恢复删除的规则以提高安全性：

iptables -A FORWARD -j DROP

[shushenghong]

感谢，dmesg里看不到任何iptables的日志，是需要哪里配置么

[shushenghong]

我在vpn server的docker里，抓了个包

其中192.168.43.10是客户端ip，172.18.0.2是docker容器eth0虚拟网卡的ip

[shushenghong]

这个192.168.65.1是个什么含义，我没太明白

[shushenghong]

现在又再也不通了，关iptables都不行了，还是只能ping通，江湖救急

[shushenghong]

临时换了台linux服务器，一切正常了，估计还是和mac作为host有关系