Good day, I’ve already broken all my teeth and can’t solve the problem. There is a tunnel, essentially software built on the basis of openvpn, with its own encryption, but it doesn’t matter. There is an old profile and a new one, the configurations are identical, only the routes to the machines behind the tunnel differ. The old one works, the new one does not in terms of NAT machines behind my server, on which the client is.
LAN client my server tun ip network in tun
[192.168.0.99] → [192.168.0.193:172.30.10.6] → [172.30.10.1] → [172.31.1.11]
interfaces:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether bc:24:11:d0:5d:a3 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.193/24 brd 192.168.0.255 scope global noprefixroute enp6s18
valid_lft forever preferred_lft forever
inet6 fe80::b2f2:6041:3a83:bc49/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 172.30.10.6 peer 172.30.10.1/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::3116:d2ba:41e:863a/64 scope link stable-privacy
valid_lft forever preferred_lft forever
routes:
default via 192.168.0.1 dev enp6s18 proto dhcp src 192.168.0.193 metric 100
172.30.10.1 dev tun0 proto kernel scope link src 172.30.10.6
172.31.1.10 via 172.30.10.6 dev tun0 scope link
172.31.1.11 via 172.30.10.6 dev tun0 scope link
172.31.1.12 via 172.30.10.6 dev tun0 scope link
172.31.1.13 via 172.30.10.6 dev tun0 scope link
172.31.1.14 via 172.30.10.6 dev tun0 scope link
172.31.1.15 via 172.30.10.6 dev tun0 scope link
172.31.1.16 via 172.30.10.6 dev tun0 scope link
172.31.1.17 via 172.30.10.6 dev tun0 scope link
172.31.2.10 via 172.30.10.6 dev tun0 scope link
172.31.2.11 via 172.30.10.6 dev tun0 scope link
172.31.4.10 via 172.30.10.6 dev tun0 scope link
172.31.4.11 via 172.30.10.6 dev tun0 scope link
192.168.0.0/24 dev enp6s18 proto kernel scope link src 192.168.0.193 metric 100
iptables switched to legacy, ip_forward=1:
# Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
*mangle
:PREROUTING ACCEPT [91310:206476897]
:INPUT ACCEPT [91256:206474083]
:FORWARD ACCEPT [29:1508]
:OUTPUT ACCEPT [35421:4562085]
:POSTROUTING ACCEPT [35517:4565397]
COMMIT
# Completed on Tue Jun 10 21:47:19 2025
# Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
*raw
:PREROUTING ACCEPT [91310:206476897]
:OUTPUT ACCEPT [35422:4562477]
COMMIT
# Completed on Tue Jun 10 21:47:19 2025
# Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
*security
:INPUT ACCEPT [90569:206326151]
:FORWARD ACCEPT [12:624]
:OUTPUT ACCEPT [35422:4562477]
COMMIT
# Completed on Tue Jun 10 21:47:19 2025
# Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
*nat
:PREROUTING ACCEPT [1793:374817]
:INPUT ACCEPT [1028:222616]
:OUTPUT ACCEPT [176:12558]
:POSTROUTING ACCEPT [176:12558]
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
COMMIT
# Completed on Tue Jun 10 21:47:19 2025
# Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
*filter
:INPUT ACCEPT [960:222411]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [204:14942]
-A FORWARD -i enp6s18 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o enp6s18 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Tue Jun 10 21:47:19 2025
when i try to connect from 192.168.0.99 to 172.31.1.11 on server tcpdump says:
21:48:27.340616 enp6s18 In IP 192.168.0.99.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:48:27.340663 tun0 Out IP 172.30.10.6.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:48:27.375856 tun0 In IP 172.31.1.11.22 > 172.30.10.6.44205: Flags [S.], seq 447303237, ack 4168098297, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:48:27.375884 tun0 Out IP 172.30.10.6 > 172.31.1.11: ICMP time exceeded in-transit, length 60
21:48:28.353241 enp6s18 In IP 192.168.0.99.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:48:28.353267 tun0 Out IP 172.30.10.6.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:48:30.367068 enp6s18 In IP 192.168.0.99.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:48:30.367113 tun0 Out IP 172.30.10.6.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
It looks like the packet is not being returned back to the original requesting machine and I don’t understand why. Even though a similar profile works (but there is a neighboring piece of hardware and I can’t find out the configuration of both anyway, although the administrator says that they are identical)
what am i doing wrong?
