Skip to contentSkip to conversation

NAT-PMP connections not tracked with nf_conntrack

DISCUSSION Mr Dash Four 2 participants 9 messages Oct 13, 2010 – Nov 15, 2010

lore
Share & tools
lore
#0 lore raw

I have configured a personal vpn with NAT-PMP (which extends from my local to the remote vpn endpoints), but that connection does not appear to be tracked by the nf_conntrack. I see the connection made in netstat, but not in nf_conntrack. Is that a bug or is there any other way I can track this connection?

#1 lore raw
Quoted 3 lines · Mr Dash Four

I have configured a personal vpn with NAT-PMP (which extends from my local to the remote vpn endpoints), but that connection does not appear to be tracked by the nf_conntrack.

Are you using any NOTRACK rules?

Quoted 2 lines

I see the connection made in netstat, but not in nf_conntrack. Is that a bug or is there any other way I can track this connection?

#2 lore raw
Quoted 6 lines
Quoted 3 lines

I have configured a personal vpn with NAT-PMP (which extends from my local to the remote vpn endpoints), but that connection does not appear to be tracked by the nf_conntrack.

Are you using any NOTRACK rules?

Not that I am aware of (I use Shorewall). How do I check that?

#3 lore raw
Quoted 10 lines · Mr Dash Four
Quoted 8 lines
Quoted 5 lines

I have configured a personal vpn with NAT-PMP (which extends from my local to the remote vpn endpoints), but that connection does not appear to be tracked by the nf_conntrack.

Are you using any NOTRACK rules?

Not that I am aware of (I use Shorewall). How do I check that?

ip6tables-save, or its respective v4 part.

#4 lore raw
Quoted 3 lines

ip6tables-save, or its respective v4 part.

iptables-save | grep NOTRACK returns nothing, so I assume that I am not using this.

#5 lore raw
Quoted 5 lines
Quoted 4 lines

ip6tables-save, or its respective v4 part.

iptables-save | grep NOTRACK returns nothing, so I assume that I am not using this.

Any ideas? The connection is definitely not tracked and could be seen with netstat from local to the remote point on the VPN.

#6 lore raw
Quoted 8 lines · Mr Dash Four
Quoted 5 lines
Quoted 3 lines

ip6tables-save, or its respective v4 part.

iptables-save | grep NOTRACK returns nothing, so I assume that I am not using this.

Any ideas? The connection is definitely not tracked and could be seen with netstat from local to the remote point on the VPN.

No idea. If I were to look at the system directly maybe.

#7 lore raw
Quoted 7 lines
Quoted 4 lines

Any ideas? The connection is definitely not tracked and could be seen with netstat from local to the remote point on the VPN.

No idea. If I were to look at the system directly maybe.

If I can help you with providing some more info I would - just let me know, but the connection is definitely there and is definitely not tracked. When I execute 'netstat --inet -an' I get it listed, like:

udp 0 0 10.1.1.2:51602 10.1.1.1:5351 ESTABLISHED

This is not showing with "cat /proc/net/nf_conntrack | grep 5351" or "cat /proc/net/nf_conntrack | grep 51602"

#8 lore raw
Quoted 7 lines · Mr Dash Four
Quoted 7 lines
Quoted 4 lines

Any ideas? The connection is definitely not tracked and could be seen with netstat from local to the remote point on the VPN.

No idea. If I were to look at the system directly maybe.

Quoted 8 lines

If I can help you with providing some more info I would - just let me know, but the connection is definitely there and is definitely not tracked. When I execute 'netstat --inet -an' I get it listed, like:
udp 0 0 10.1.1.2:51602 10.1.1.1:5351
ESTABLISHED

This is not showing with "cat /proc/net/nf_conntrack | grep 5351" or "cat /proc/net/nf_conntrack | grep 51602"

Well yes you said that already. BTW, netstat is obsolete, use ss. The cat is also not necessary (Useless use of cat), just use grep, but alas, the conntrack the utility is a better solution.

The first thing I'd probably do is add a -p udp --dport 5351 -j LOGMARK (xtables-addons) target rule in the mangle table to check for the ct status. After that, it's pretty much kernel code debugging in nf_conntrack_proto_udp.c, doing a spatial bisect for where the ct gets (not) created.