Connection tracking stores wrong port for DNAT

Connection tracking stores wrong port for DNAT

[Justin Michael Schwartzbeck]

Hello,

I have a box that DNATs incoming HTTP/HTTPS traffic transparently to a
proxy server and also masquerades all other outgoing traffic (like a
NAT box). I am using the nf_conntrack_find_get to try and find the
associated connection for an outgoing HTTP connection from the client.
Here are the details for this packet:

Source IP: 192.168.4.1
Dest IP: 23.235.43.73
Source Port: 60324
Destination Port: 80

When I create a tuple for this packet and do a lookup, it is unable to
find the associated connection. Now here's the interesting part. When
I do a cat on /proc/net/nf_conntrack I see the following line that is
associated with the connection:

ipv4     2 tcp      6 299 ESTABLISHED src=192.168.4.1 dst=23.235.43.73
sport=1048 dport=80 src=10.10.1.5 dst=10.10.1.151 sport=8080
dport=1048 [ASSURED] mark=0 secmark=0 use=2

This is obviously the associated connection with that packet. However,
the sport for the client side is wrong. It is set equal to the dport
for the reply tuple. Does anyone know why this would be? How exactly
does connection tracking work, and why would it be showing the wrong
port here? Could this be because of the IP masquerading? There must be
a place where the connection mapping is done properly otherwise the
IPTables firewall wouldn't know where to route the packet in question.
Is there perhaps another lookup function somewhere that would give me
the proper information?

Thanks in advance!
-Justin

Connection tracking stores wrong port for DNAT

[Justin Michael Schwartzbeck]

Hello,

I have a box that DNATs incoming HTTP/HTTPS traffic transparently to a
proxy server and also masquerades all other outgoing traffic (like a
NAT box). I am using the nf_conntrack_find_get to try and find the
associated connection for an outgoing HTTP connection from the client.
Here are the details for this packet:

Source IP: 192.168.4.1
Dest IP: 23.235.43.73
Source Port: 60324
Destination Port: 80

When I create a tuple for this packet and do a lookup, it is unable to
find the associated connection. Now here's the interesting part. When
I do a cat on /proc/net/nf_conntrack I see the following line that is
associated with the connection:

ipv4     2 tcp      6 299 ESTABLISHED src=192.168.4.1 dst=23.235.43.73
sport=1048 dport=80 src=10.10.1.5 dst=10.10.1.151 sport=8080
dport=1048 [ASSURED] mark=0 secmark=0 use=2

This is obviously the associated connection with that packet. However,
the sport for the client side is wrong. It is set equal to the dport
for the reply tuple. Does anyone know why this would be? How exactly
does connection tracking work, and why would it be showing the wrong
port here? Could this be because of the IP masquerading? There must be
a place where the connection mapping is done properly otherwise the
IPTables firewall wouldn't know where to route the packet in question.
Is there perhaps another lookup function somewhere that would give me
the proper information?

Thanks in advance!