0

I use debian 10 with kernel 4.19 and nftables as port forwarding tool. The rule is like

table ip nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
        ip daddr 10.250.181.103 tcp dport 25565 counter packets 0 bytes 0 log
        ip daddr 10.250.181.103 tcp dport 25568 counter packets 0 bytes 0 log
        ip daddr 10.250.181.103 tcp dport 25573 counter packets 0 bytes 0 log
        ip daddr 10.250.181.103 tcp dport 25565 counter packets 0 bytes 0 dnat to 192.168.56.1:25565
        ip daddr 10.250.181.103 tcp dport 25568 counter packets 0 bytes 0 dnat to 192.168.56.1:25568
        ip daddr 10.250.181.103 tcp dport 25573 counter packets 0 bytes 0 dnat to 192.168.56.1:25573
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        ip saddr != 192.168.56.0/24 ip daddr 192.168.56.0/24 counter packets 0 bytes 0 masquerade
    }
}

(The SNAT is because of 192.168.56.1 is Windows and does not support policy-based routing)

The port forwarding work well when I ssh to the system. However, it does not work after several seconds I log out from it.

What configs can I check to find out the reason?

Improve this question
5
  • You could use conntrack -L or better keep conntrack -E running to see what are the "mappings" done during NAT and if something strange appears when it doesn't work anymore. – A.B Apr 26 '20 at 9:39
  • @A.B "the system" is a virtual machine and in the same local network 192.168.56.0/24 with the host machine. It has another network interface and uses wireguard as tunnel to the very public gateway and internal ip is 10.250.181.103 (peer: 10.250.181.1). "ssh to the system" means I ssh to 192.168.56.101 from 192.168.56.1 as a non-root user. – Steven Yang Apr 26 '20 at 10:13
  • The conntrack -E in tmux shows [NEW] tcp 6 120 SYN_SENT src=<accesser ip> dst=10.250.181.103 sport=56978 dport=25568 [UNREPLIED] src=192.168.56.1 dst=192.168.56.101 sport=25568 dport=56978 when the connection fails. – Steven Yang Apr 26 '20 at 10:14
  • Well, it seems not to be the problem of the system. The system cannot connect to 192.168.56.1 itself and pinning the 192.168.56.1 continuously in tmux seems to solve the problem. – Steven Yang Apr 26 '20 at 10:33
  • If you are accessing using wireguard and it's NAT'ed (by what? windows?) and initiated from your setup, then when the NAT times out communication fails. The question should be complete and stating that a tunnel is used, how etc. Here guesses must be done in comments which isn't good. You can edit the question. Also it's quite possible the issue is on windows then, which would be half off topic on UL SE. Wireguard has keep alive options however. – A.B Apr 26 '20 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.