Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
* masquerading AFTER first packet
@ 2021-09-01 20:42 folkert
2021-09-02 16:26 ` Florian Westphal
0 siblings, 1 reply; 6+ messages in thread
From: folkert @ 2021-09-01 20:42 UTC (permalink / raw)
To: netdev
Hi,
I'm seeing something strange. I'm doing an snmpwalk on an snmp server of
mine (behing DNAT) , and after the first response it goes into a timeout.
I did a tcpdump and saw this:
1630528031.843264 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(23) .1.3.6.1
1630528031.843924 IP 37.34.63.177.161 > 185.243.112.54.38377: GetResponse(34) .1.3.6.1.2=0 <-- ok
1630528031.846950 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(24) .1.3.6.1.2
1630528031.847415 IP 192.168.4.2.161 > 185.243.112.54.38377: GetResponse(35) .1.3.6.1.2.1=0 <-- fail
1630528032.847649 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(24) .1.3.6.1.2
1630528032.848081 IP 192.168.4.2.161 > 185.243.112.54.38377: GetResponse(35) .1.3.6.1.2.1=0 <-- fail
...
What happens here: 192.168.4.2.161 is the snmp-server. It is
portforwarded by 37.34.63.177 and also masqueraded. All is fine for the
first request/response, after that as you see the internal ip address
is outputted (which is incorrect of course).
I thought that maybe I had the nat-connection tracking wrong but
everywhere on the internet it is written like this:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 161 -j LOG --log-prefix "DNAT: " --log-level 4
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 161 -j DNAT --to 192.168.4.2:161
iptables -A FORWARD -d 192.168.4.2 -p udp --dport 161 -j LOG --log-prefix "FWD: " --log-level 4
iptables -A FORWARD -d 192.168.4.2 -p udp --dport 161 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
eth0 is the interface to the world, eth1 to the internal system.
An example pcap trace file is at: https://vps001.vanheusden.com/~folkert/masq.pcap
Also dmesg says:
[Wed Sep 1 22:40:08 2021] DNAT: IN=eth0 OUT= MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=37.34.63.177 LEN=66 TOS=0x00 PREC=0x00 TTL=55 ID=32612 DF PROTO=UDP SPT=39397 DPT=161 LEN=46
[Wed Sep 1 22:40:08 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=66 TOS=0x00 PREC=0x00 TTL=54 ID=32612 DF PROTO=UDP SPT=39397 DPT=161 LEN=46
[Wed Sep 1 22:40:08 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=32613 DF PROTO=UDP SPT=39397 DPT=161 LEN=47
...
Notice that 'DNAT' is logged once while the FWD for each packet.
Any suggestions?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: masquerading AFTER first packet
2021-09-01 20:42 masquerading AFTER first packet folkert
@ 2021-09-02 16:26 ` Florian Westphal
2021-09-02 17:48 ` folkert
0 siblings, 1 reply; 6+ messages in thread
From: Florian Westphal @ 2021-09-02 16:26 UTC (permalink / raw)
To: folkert; +Cc: netdev
folkert <folkert@vanheusden.com> wrote:
> Hi,
>
> I'm seeing something strange. I'm doing an snmpwalk on an snmp server of
> mine (behing DNAT) , and after the first response it goes into a timeout.
> I did a tcpdump and saw this:
>
> 1630528031.843264 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(23) .1.3.6.1
> 1630528031.843924 IP 37.34.63.177.161 > 185.243.112.54.38377: GetResponse(34) .1.3.6.1.2=0 <-- ok
> 1630528031.846950 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(24) .1.3.6.1.2
> 1630528031.847415 IP 192.168.4.2.161 > 185.243.112.54.38377: GetResponse(35) .1.3.6.1.2.1=0 <-- fail
> 1630528032.847649 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(24) .1.3.6.1.2
> 1630528032.848081 IP 192.168.4.2.161 > 185.243.112.54.38377: GetResponse(35) .1.3.6.1.2.1=0 <-- fail
Looks like a kernel bug, but you did not include kernel version.
Please also show 'ethtool -k' for in and out interfaces.
You might want to try and disable udp releated offload settings to see
if that helps.
e.g.
c3df39ac9b0e3747bf8233ea9ce4ed5ceb3199d3,
"udp: ipv4: manipulate network header of NATed UDP GRO fraglist"
which fixed a bug where only first packet of GRO'd udp train would
have nat applied, (was broken between 5.6 and 5.11)
Other explanation is that conntrack thinks only first packet is valid,
you can check this for example via
sysctl net.netfilter.nf_conntrack_acct=1
and then checking if 'conntrack -L' shows increasing packet/byte
counters or is stuck at '1'.
If the remaining packets are indeed invalid, try setting
sysctl net.netfilter.nf_conntrack_log_invalid=17
(17 == udp).
and see if that shows something relevant.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: masquerading AFTER first packet
2021-09-02 16:26 ` Florian Westphal
@ 2021-09-02 17:48 ` folkert
2021-09-02 20:07 ` Florian Westphal
0 siblings, 1 reply; 6+ messages in thread
From: folkert @ 2021-09-02 17:48 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 8700 bytes --]
> > I'm seeing something strange. I'm doing an snmpwalk on an snmp server of
> > mine (behing DNAT) , and after the first response it goes into a timeout.
> > I did a tcpdump and saw this:
> >
> > 1630528031.843264 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(23) .1.3.6.1
> > 1630528031.843924 IP 37.34.63.177.161 > 185.243.112.54.38377: GetResponse(34) .1.3.6.1.2=0 <-- ok
> > 1630528031.846950 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(24) .1.3.6.1.2
> > 1630528031.847415 IP 192.168.4.2.161 > 185.243.112.54.38377: GetResponse(35) .1.3.6.1.2.1=0 <-- fail
> > 1630528032.847649 IP 185.243.112.54.38377 > 37.34.63.177.161: GetNextRequest(24) .1.3.6.1.2
> > 1630528032.848081 IP 192.168.4.2.161 > 185.243.112.54.38377: GetResponse(35) .1.3.6.1.2.1=0 <-- fail
>
> Looks like a kernel bug, but you did not include kernel version.
I'm definately seeing this with 5.10.0-8-amd64 (debian bullseye on a
vps) and I may have seen it with 4.9.0-5 as well (same system).
> Please also show 'ethtool -k' for in and out interfaces.
Included as attachment.
> You might want to try and disable udp releated offload settings to see
> if that helps.
If offloading is the problem, wouldn't the first packet fail as well?
> e.g.
> c3df39ac9b0e3747bf8233ea9ce4ed5ceb3199d3,
> "udp: ipv4: manipulate network header of NATed UDP GRO fraglist"
> which fixed a bug where only first packet of GRO'd udp train would
> have nat applied, (was broken between 5.6 and 5.11)
Ok I tried "ethtool -K eth* gro off" but it made no difference.
> Other explanation is that conntrack thinks only first packet is valid,
> you can check this for example via
>
> sysctl net.netfilter.nf_conntrack_acct=1
>
> and then checking if 'conntrack -L' shows increasing packet/byte
> counters or is stuck at '1'.
root@vps001:~# while true ; do conntrack -L 2>&1 | grep port=161 ; sleep 1 ; done
udp 17 3 src=185.243.112.54 dst=37.34.63.177 sport=40873 dport=161 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=40873 [ASSURED] mark=0 use=1
udp 17 2 src=185.243.112.54 dst=37.34.63.177 sport=40873 dport=161 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=40873 [ASSURED] mark=0 use=1
udp 17 1 src=185.243.112.54 dst=37.34.63.177 sport=40873 dport=161 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=40873 [ASSURED] mark=0 use=1
udp 17 29 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=2 bytes=133 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
udp 17 0 src=185.243.112.54 dst=37.34.63.177 sport=40873 dport=161 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=40873 [ASSURED] mark=0 use=1
udp 17 29 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=3 bytes=200 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=4 bytes=267 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=5 bytes=334 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=6 bytes=401 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=7 bytes=468 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
udp 17 118 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=7 bytes=468 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
...
So yes, increating packet/byte counters.
> If the remaining packets are indeed invalid, try setting
> sysctl net.netfilter.nf_conntrack_log_invalid=17
[Thu Sep 2 19:40:54 2021] DNAT: IN=eth0 OUT= MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=37.34.63.177 LEN=66 TOS=0x00 PREC=0x00 TTL=55 ID=1501 DF PROTO=UDP SPT=56523 DPT=161 LEN=46
[Thu Sep 2 19:40:54 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=66 TOS=0x00 PREC=0x00 TTL=54 ID=1501 DF PROTO=UDP SPT=56523 DPT=161 LEN=46
[Thu Sep 2 19:40:54 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=1502 DF PROTO=UDP SPT=56523 DPT=161 LEN=47
[Thu Sep 2 19:40:54 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
[Thu Sep 2 19:40:55 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=1637 DF PROTO=UDP SPT=56523 DPT=161 LEN=47
[Thu Sep 2 19:40:55 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
[Thu Sep 2 19:40:56 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=1700 DF PROTO=UDP SPT=56523 DPT=161 LEN=47
[Thu Sep 2 19:40:56 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
[Thu Sep 2 19:40:57 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=1859 DF PROTO=UDP SPT=56523 DPT=161 LEN=47
[Thu Sep 2 19:40:57 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
[Thu Sep 2 19:40:58 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=1946 DF PROTO=UDP SPT=56523 DPT=161 LEN=47
[Thu Sep 2 19:40:58 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
[Thu Sep 2 19:40:59 2021] FWD: IN=eth0 OUT=eth1 MAC=52:54:00:65:21:38:0c:86:10:b5:91:e0:08:00 SRC=185.243.112.54 DST=192.168.4.2 LEN=67 TOS=0x00 PREC=0x00 TTL=54 ID=2131 DF PROTO=UDP SPT=56523 DPT=161 LEN=47
[Thu Sep 2 19:40:59 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
Those 'bad checksum's are interesting:
root@vps001:~# tcpdump -r sep02.pcap -vv | grep 'udp sum ok'
reading from file test.pcap, link-type EN10MB (Ethernet), snapshot length 1600
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(23) R=1216445187 .iso.org.dod.internet } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(34) R=1216445187 .iso.org.dod.internet.mgmt=0 } }
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(24) R=1216445188 .iso.org.dod.internet.mgmt } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(35) R=1216445188 =0 } }
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(24) R=1216445188 .iso.org.dod.internet.mgmt } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(35) R=1216445188 =0 } }
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(24) R=1216445188 .iso.org.dod.internet.mgmt } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(35) R=1216445188 =0 } }
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(24) R=1216445188 .iso.org.dod.internet.mgmt } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(35) R=1216445188 =0 } }
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(24) R=1216445188 .iso.org.dod.internet.mgmt } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(35) R=1216445188 =0 } }
185.243.112.54.56523 > 192.168.4.2.snmp: [udp sum ok] { SNMPv1 { GetNextRequest(24) R=1216445188 .iso.org.dod.internet.mgmt } }
192.168.4.2.snmp > 185.243.112.54.56523: [udp sum ok] { SNMPv1 { GetResponse(35) R=1216445188 =0 } }
As you see, tcpdump says they're fine.
[-- Attachment #2: eth0.txt --]
[-- Type: text/plain, Size: 1786 bytes --]
Features for eth0:
rx-checksumming: on [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: on [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
[-- Attachment #3: eth1.txt --]
[-- Type: text/plain, Size: 1836 bytes --]
Features for myip:
rx-checksumming: off [fixed]
tx-checksumming: off
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: off [requested on]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [requested on]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
[-- Attachment #4: sep02.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 1484 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: masquerading AFTER first packet
2021-09-02 17:48 ` folkert
@ 2021-09-02 20:07 ` Florian Westphal
2021-09-02 20:54 ` folkert
0 siblings, 1 reply; 6+ messages in thread
From: Florian Westphal @ 2021-09-02 20:07 UTC (permalink / raw)
To: folkert; +Cc: Florian Westphal, netdev
folkert <folkert@vanheusden.com> wrote:
> > You might want to try and disable udp releated offload settings to see
> > if that helps.
>
> If offloading is the problem, wouldn't the first packet fail as well?
No, not necessarily, I recall a bug with fraglist udp where only first
packet in the batch had headers changed.
[..]
> udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=4 bytes=267 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
> udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=5 bytes=334 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
> udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=6 bytes=401 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
> udp 17 119 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=7 bytes=468 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
> udp 17 118 src=185.243.112.54 dst=37.34.63.177 sport=52775 dport=161 packets=7 bytes=468 src=192.168.4.2 dst=185.243.112.54 sport=161 dport=52775 packets=1 bytes=80 [ASSURED] mark=0 use=1
> ...
>
> So yes, increating packet/byte counters.
[..]
> [Thu Sep 2 19:40:54 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
So reverse direction packets are deemed invalid and are thus not reverse-translated.
This is a bug, but not sure where. What driver/nic is feeding these
packets to stack?
sysctl net.netfilter.nf_conntrack_checksum=0
should make things "work".
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: masquerading AFTER first packet
2021-09-02 20:07 ` Florian Westphal
@ 2021-09-02 20:54 ` folkert
2021-09-05 8:39 ` folkert
0 siblings, 1 reply; 6+ messages in thread
From: folkert @ 2021-09-02 20:54 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
> > [Thu Sep 2 19:40:54 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
>
> So reverse direction packets are deemed invalid and are thus not reverse-translated.
>
> This is a bug, but not sure where. What driver/nic is feeding these
> packets to stack?
> sysctl net.netfilter.nf_conntrack_checksum=0
> should make things "work".
Indeed it does!
"The other end", the one feeding the packets, is a toy IP-stack
implementation of myself. I verified the correctness of the IP/UDP
checksums by looking at wireshark (after enabling them) and tcpdump;
they both say all is fine (else I wouldn't bother this mailinglist with
this). https://github.com/folkertvanheusden/myip by the way (not a full
implementation, just the bare essentials to get tcp/udp working).
Now there are also situations (different ISPs/VPS providers) where
no packets at all are received (and situations where all are received!).
I guess that can be explained by that some are less strict than others.
So conclusion: my IP-stack *may* be producing incorrect checksums, or
Linux or tcpdump and wireshark may be incorrectly evaluating them?
Folkert.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: masquerading AFTER first packet
2021-09-02 20:54 ` folkert
@ 2021-09-05 8:39 ` folkert
0 siblings, 0 replies; 6+ messages in thread
From: folkert @ 2021-09-05 8:39 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
> So conclusion: my IP-stack *may* be producing incorrect checksums, or
> Linux or tcpdump and wireshark may be incorrectly evaluating them?
I'm sceptical about the incorrect checksum hypothesis.
That would be wireshark, tcpdump, my own ip-stack and a quick python-
script that verifies checksums all disagreeing with the kernel in this
specific case.
https://github.com/folkertvanheusden/MyIP/blob/master/netverify.py
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-05 8:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-01 20:42 masquerading AFTER first packet folkert
2021-09-02 16:26 ` Florian Westphal
2021-09-02 17:48 ` folkert
2021-09-02 20:07 ` Florian Westphal
2021-09-02 20:54 ` folkert
2021-09-05 8:39 ` folkert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).