* 2.6.16-rc1-mm3 XFRM+NAT issue
@ 2006-01-29 19:41 Christophe Saout
2006-01-29 19:57 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Christophe Saout @ 2006-01-29 19:41 UTC (permalink / raw)
To: netfilter-devel; +Cc: Patrick McHardy, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
Hi,
I'm very glad that you found some time to get these patches into the
mainline kernel. Unfortunately I think I'm running into a case where
it's not working (it's working with 2.6.12 + the old unofficial IPSEC
+NAT patches).
.--- gateway host ---. .-- pub. host -.
priv net -|NAT + IPSEC endpoint|- internet -|IPSEC endpoint|
'--------------------' '--------------'
ping ----->---*NAT*---*XFRM*********>*********XFRM*--------.
v
???.....*********<*********XFRM*- pong -'
Without IPSEC turned on I can reach the host on the far right from any
host in the private network on the left without problem. The private
address is source-NATted (masqueraeded) at the gateway.
When turning on the IPSEC connection between the gateway and the
internet host, the host in the private network can't reach the internet
host (on the right) anymore. It's still reachable from the gateway
itself though.
When pinging from the host behind the gateway the packet passes through
the gateway, gets to the internet host, which responds to the ping and
sends an encrypted packet back through the IPSEC connection which then
arrives at the gatway. But then the gateway simply ignores the packet
instead of decapsulating and DNATting it back to the host in the private
network. At least that's what I can gather from tcpdump. If I run
tcpdump on ppp0 on the gateway I can see encrypted packets go out to the
host on the right and encrypted packets coming back and that's it.
I couldn't exactly keep track with all the changes since 2.6.12 and I
was hoping that this kernel would just work and fulfill my needs... and
I still don't really "get" the networking stack I have no clue where to
start looking what could go wrong.
So, do you perhaps have any ideas?
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 19:41 2.6.16-rc1-mm3 XFRM+NAT issue Christophe Saout
@ 2006-01-29 19:57 ` Patrick McHardy
2006-01-29 20:59 ` Christophe Saout
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-01-29 19:57 UTC (permalink / raw)
To: Christophe Saout; +Cc: netfilter-devel, Herbert Xu
Christophe Saout wrote:
> Hi,
>
> I'm very glad that you found some time to get these patches into the
> mainline kernel. Unfortunately I think I'm running into a case where
> it's not working (it's working with 2.6.12 + the old unofficial IPSEC
> +NAT patches).
>
> .--- gateway host ---. .-- pub. host -.
> priv net -|NAT + IPSEC endpoint|- internet -|IPSEC endpoint|
> '--------------------' '--------------'
>
> ping ----->---*NAT*---*XFRM*********>*********XFRM*--------.
> v
> ???.....*********<*********XFRM*- pong -'
>
> Without IPSEC turned on I can reach the host on the far right from any
> host in the private network on the left without problem. The private
> address is source-NATted (masqueraeded) at the gateway.
>
> When turning on the IPSEC connection between the gateway and the
> internet host, the host in the private network can't reach the internet
> host (on the right) anymore. It's still reachable from the gateway
> itself though.
>
> When pinging from the host behind the gateway the packet passes through
> the gateway, gets to the internet host, which responds to the ping and
> sends an encrypted packet back through the IPSEC connection which then
> arrives at the gatway. But then the gateway simply ignores the packet
> instead of decapsulating and DNATting it back to the host in the private
> network. At least that's what I can gather from tcpdump. If I run
> tcpdump on ppp0 on the gateway I can see encrypted packets go out to the
> host on the right and encrypted packets coming back and that's it.
>
> I couldn't exactly keep track with all the changes since 2.6.12 and I
> was hoping that this kernel would just work and fulfill my needs... and
> I still don't really "get" the networking stack I have no clue where to
> start looking what could go wrong.
>
> So, do you perhaps have any ideas?
It should work just fine. Please add logging rules for both encrypted
and decrypted packets to all chains in the mangle table and enable
logging of invalid packets in connection tracking
(echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid)
and post the results.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 19:57 ` Patrick McHardy
@ 2006-01-29 20:59 ` Christophe Saout
2006-01-29 22:14 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Christophe Saout @ 2006-01-29 20:59 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 5621 bytes --]
Patrick McHardy wrote:
> > I'm very glad that you found some time to get these patches into the
> > mainline kernel. Unfortunately I think I'm running into a case where
> > it's not working (it's working with 2.6.12 + the old unofficial IPSEC
> > +NAT patches).
> >
> > .--- gateway host ---. .-- pub. host -.
> > priv net -|NAT + IPSEC endpoint|- internet -|IPSEC endpoint|
> > '--------------------' '--------------'
> >
> > ping ----->---*NAT*---*XFRM*********>*********XFRM*--------.
> > v
> > ???.....*********<*********XFRM*- pong -'
> >
> > Without IPSEC turned on I can reach the host on the far right from any
> > host in the private network on the left without problem. The private
> > address is source-NATted (masqueraeded) at the gateway.
> >
> > When turning on the IPSEC connection between the gateway and the
> > internet host, the host in the private network can't reach the internet
> > host (on the right) anymore. It's still reachable from the gateway
> > itself though.
> >
> > When pinging from the host behind the gateway the packet passes through
> > the gateway, gets to the internet host, which responds to the ping and
> > sends an encrypted packet back through the IPSEC connection which then
> > arrives at the gatway. But then the gateway simply ignores the packet
> > instead of decapsulating and DNATting it back to the host in the private
> > network. At least that's what I can gather from tcpdump. If I run
> > tcpdump on ppp0 on the gateway I can see encrypted packets go out to the
> > host on the right and encrypted packets coming back and that's it.
>
> It should work just fine. Please add logging rules for both encrypted
> and decrypted packets to all chains in the mangle table and enable
> logging of invalid packets in connection tracking
> (echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid)
> and post the results.
I did, but it doesn't seem conclusive.
Trying to open a tcp connection: (note that there are no entries with
IN=eth0 ???)
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=100 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=41
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=100 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=41
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0x1249d895
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0x1249d895
Jan 29 21:51:23 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=152 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0xbdbf1ca7
Jan 29 21:51:23 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=152 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0xbdbf1ca7
Jan 29 21:51:23 server IN=ppp0 OUT= MAC=45:00:00:98:00:00:40:00:37:29:56:8d:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=<gateway pub ip> LEN=100 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=41
Jan 29 21:51:23 server IN=ppp0 OUT= MAC=45:00:00:98:00:00:40:00:37:29:56:8d:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=<gateway pub ip> LEN=100 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=41
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=41
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=41
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=200 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0x1249d895
Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=200 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0x1249d895
Pinging inet host from behind NAT:
Jan 29 21:51:42 server IN=eth0 OUT= MAC=00:01:80:5c:0f:48:00:02:8a:ba:b8:58:08:00 SRC=192.168.80.90 DST=<inet host> LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=48978 SEQ=1
Jan 29 21:51:42 server IN=eth0 OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=48978 SEQ=1
Jan 29 21:51:42 server IN= OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=48978 SEQ=1
Jan 29 21:51:42 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=136 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ESP SPI=0x1249d895
Jan 29 21:51:42 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=136 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ESP SPI=0x1249d895
Jan 29 21:51:42 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=136 TOS=0x00 PREC=0x00 TTL=55 ID=20240 PROTO=ESP SPI=0xbdbf1ca7
Jan 29 21:51:42 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=136 TOS=0x00 PREC=0x00 TTL=55 ID=20240 PROTO=ESP SPI=0xbdbf1ca7
Jan 29 21:51:42 server IN=ppp0 OUT= MAC=45:00:00:88:4f:10:00:00:37:01:47:8d:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=<gateway pub ip> LEN=84 TOS=0x00 PREC=0x00 TTL=55 ID=20240 PROTO=ICMP TYPE=0 CODE=0 ID=48978 SEQ=1
Jan 29 21:51:42 server IN=ppp0 OUT= MAC=45:00:00:88:4f:10:00:00:37:01:47:8d:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=192.168.80.90 LEN=84 TOS=0x00 PREC=0x00 TTL=55 ID=20240 PROTO=ICMP TYPE=0 CODE=0 ID=48978 SEQ=1
Perhaps I also should note that *tunnel* mode works fine, it's just the
transport mode that is broken.
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 20:59 ` Christophe Saout
@ 2006-01-29 22:14 ` Patrick McHardy
2006-01-29 22:30 ` Christophe Saout
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-01-29 22:14 UTC (permalink / raw)
To: Christophe Saout; +Cc: netfilter-devel, Herbert Xu
Christophe Saout wrote:
> Patrick McHardy wrote:
>
>>It should work just fine. Please add logging rules for both encrypted
>>and decrypted packets to all chains in the mangle table and enable
>>logging of invalid packets in connection tracking
>>(echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid)
>>and post the results.
>
>
> I did, but it doesn't seem conclusive.
>
> Trying to open a tcp connection: (note that there are no entries with
> IN=eth0 ???)
>
> Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=100 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=41
> Jan 29 21:51:23 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=100 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=41
41 is IPPROTO_IPV6, you seem to be talking to the remote side using IPv6
over sit, which is why NAT on the TCP packet doesn't work.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 22:14 ` Patrick McHardy
@ 2006-01-29 22:30 ` Christophe Saout
2006-01-29 22:43 ` Patrick McHardy
2006-01-29 22:59 ` Patrick McHardy
0 siblings, 2 replies; 14+ messages in thread
From: Christophe Saout @ 2006-01-29 22:30 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]
Am Sonntag, den 29.01.2006, 23:14 +0100 schrieb Patrick McHardy:
> 41 is IPPROTO_IPV6, you seem to be talking to the remote side using IPv6
> over sit, which is why NAT on the TCP packet doesn't work.
Ok, I'm stupid, forget this, IPv6 is a completely different issue. It's
really IPv4 that isn't working.
This time with -4 on the command line:
Jan 29 23:27:38 server IN=eth0 OUT= MAC=00:01:80:5c:0f:48:00:02:8a:ba:b8:58:08:00 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=38799 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 29 23:27:38 server IN=eth0 OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=104 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=ESP SPI=0x1249d895
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=104 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=ESP SPI=0x1249d895
Jan 29 23:27:38 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=104 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0xbdbf1ca7
Jan 29 23:27:38 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=104 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0xbdbf1ca7
Jan 29 23:27:38 server IN=ppp0 OUT= MAC=45:00:00:68:00:00:40:00:37:06:56:bd:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=<gateway pub ip> LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=25 DPT=40255 WINDOW=5792 RES=0x00 ECE ACK SYN URGP=0
Jan 29 23:27:38 server IN=ppp0 OUT= MAC=45:00:00:68:00:00:40:00:37:06:56:bd:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=192.168.80.90 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=25 DPT=40255 WINDOW=5792 RES=0x00 ECE ACK SYN URGP=0
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=ESP SPI=0x1249d895
Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=ESP SPI=0x1249d895
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 22:30 ` Christophe Saout
@ 2006-01-29 22:43 ` Patrick McHardy
2006-01-29 23:11 ` Christophe Saout
2006-01-29 22:59 ` Patrick McHardy
1 sibling, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-01-29 22:43 UTC (permalink / raw)
To: Christophe Saout; +Cc: netfilter-devel, Herbert Xu
Christophe Saout wrote:
> This time with -4 on the command line:
>
Please also add the chain names to the logging rules.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 22:43 ` Patrick McHardy
@ 2006-01-29 23:11 ` Christophe Saout
0 siblings, 0 replies; 14+ messages in thread
From: Christophe Saout @ 2006-01-29 23:11 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]
Am Sonntag, den 29.01.2006, 23:43 +0100 schrieb Patrick McHardy:
> > This time with -4 on the command line:
>
> Please also add the chain names to the logging rules.
Good idea.
Jan 29 23:58:31 server PREROUTING IN=eth0 OUT= MAC=00:01:80:5c:0f:48:00:02:8a:ba:b8:58:08:00 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=51295 DF PROTO=TCP SPT=33806 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 29 23:58:31 server FORWARD IN=eth0 OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=51295 DF PROTO=TCP SPT=33806 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 29 23:58:31 server POSTROUTING IN= OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=51295 DF PROTO=TCP SPT=33806 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 29 23:58:31 server OUTPUT IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=104 TOS=0x10 PREC=0x00 TTL=63 ID=51295 DF PROTO=ESP SPI=0xe2d41c8
Jan 29 23:58:31 server POSTROUTING IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=104 TOS=0x10 PREC=0x00 TTL=63 ID=51295 DF PROTO=ESP SPI=0xe2d41c8
Jan 29 23:58:31 server PREROUTING IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=104 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0x865c0e26
Jan 29 23:58:31 server INPUT IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=104 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0x865c0e26
Jan 29 23:58:31 server PREROUTING IN=ppp0 OUT= MAC=45:00:00:68:00:00:40:00:37:06:61:ee:d5:ef:c5:f1:54:38:f1:5c:86:5c SRC=<inet host> DST=<gateway pub ip> LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=25 DPT=33806 WINDOW=5792 RES=0x00 ECE ACK SYN URGP=0
Jan 29 23:58:31 server INPUT IN=ppp0 OUT= MAC=45:00:00:68:00:00:40:00:37:06:61:ee:d5:ef:c5:f1:54:38:f1:5c:86:5c SRC=<inet host> DST=192.168.80.90 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=25 DPT=33806 WINDOW=5792 RES=0x00 ECE ACK SYN URGP=0
-- Something seems to go wrong here.
Jan 29 23:58:31 server OUTPUT IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=6 DF PROTO=TCP SPT=33806 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Jan 29 23:58:31 server POSTROUTING IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=6 DF PROTO=TCP SPT=33806 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Jan 29 23:58:31 server OUTPUT IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=6 DF PROTO=ESP SPI=0xe2d41c8
Jan 29 23:58:31 server POSTROUTING IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=6 DF PROTO=ESP SPI=0xe2d41c8
There are no messages about invalid connections or so.
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 22:30 ` Christophe Saout
2006-01-29 22:43 ` Patrick McHardy
@ 2006-01-29 22:59 ` Patrick McHardy
2006-01-29 23:24 ` Christophe Saout
2006-02-03 1:16 ` David S. Miller
1 sibling, 2 replies; 14+ messages in thread
From: Patrick McHardy @ 2006-01-29 22:59 UTC (permalink / raw)
To: Christophe Saout; +Cc: netfilter-devel, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]
Christophe Saout wrote:
> Am Sonntag, den 29.01.2006, 23:14 +0100 schrieb Patrick McHardy:
>
>
>>41 is IPPROTO_IPV6, you seem to be talking to the remote side using IPv6
>>over sit, which is why NAT on the TCP packet doesn't work.
>
>
> Ok, I'm stupid, forget this, IPv6 is a completely different issue. It's
> really IPv4 that isn't working.
>
> This time with -4 on the command line:
>
> Jan 29 23:27:38 server IN=eth0 OUT= MAC=00:01:80:5c:0f:48:00:02:8a:ba:b8:58:08:00 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=38799 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
> Jan 29 23:27:38 server IN=eth0 OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=192.168.80.90 DST=<inet host> LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=104 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=ESP SPI=0x1249d895
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=104 TOS=0x10 PREC=0x00 TTL=63 ID=38799 DF PROTO=ESP SPI=0x1249d895
> Jan 29 23:27:38 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=104 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0xbdbf1ca7
> Jan 29 23:27:38 server IN=ppp0 OUT= MAC= SRC=<inet host> DST=<gateway pub ip> LEN=104 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ESP SPI=0xbdbf1ca7
> Jan 29 23:27:38 server IN=ppp0 OUT= MAC=45:00:00:68:00:00:40:00:37:06:56:bd:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=<gateway pub ip> LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=25 DPT=40255 WINDOW=5792 RES=0x00 ECE ACK SYN URGP=0
> Jan 29 23:27:38 server IN=ppp0 OUT= MAC=45:00:00:68:00:00:40:00:37:06:56:bd:d5:ef:c5:f1:54:38:fc:8d:bd:bf SRC=<inet host> DST=192.168.80.90 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=25 DPT=40255 WINDOW=5792 RES=0x00 ECE ACK SYN URGP=0
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=TCP SPT=40255 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=ESP SPI=0x1249d895
> Jan 29 23:27:38 server IN= OUT=ppp0 SRC=<gateway pub ip> DST=<inet host> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=954 DF PROTO=ESP SPI=0x1249d895
Found it, the packet doesn't have its dst_entry released after DNAT in
PRE_ROUTING because of an incorrect check and is delivered locally.
This patch should fix it.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 609 bytes --]
diff --git a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c
index ad438fb..74633cd 100644
--- a/net/ipv4/netfilter/ip_nat_standalone.c
+++ b/net/ipv4/netfilter/ip_nat_standalone.c
@@ -209,8 +209,8 @@ ip_nat_in(unsigned int hooknum,
&& (ct = ip_conntrack_get(*pskb, &ctinfo)) != NULL) {
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
- if (ct->tuplehash[dir].tuple.src.ip !=
- ct->tuplehash[!dir].tuple.dst.ip) {
+ if (ct->tuplehash[dir].tuple.dst.ip !=
+ ct->tuplehash[!dir].tuple.src.ip) {
dst_release((*pskb)->dst);
(*pskb)->dst = NULL;
}
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 22:59 ` Patrick McHardy
@ 2006-01-29 23:24 ` Christophe Saout
2006-01-29 23:26 ` Patrick McHardy
2006-02-03 1:16 ` David S. Miller
1 sibling, 1 reply; 14+ messages in thread
From: Christophe Saout @ 2006-01-29 23:24 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 338 bytes --]
Am Sonntag, den 29.01.2006, 23:59 +0100 schrieb Patrick McHardy:
> Found it, the packet doesn't have its dst_entry released after DNAT in
> PRE_ROUTING because of an incorrect check and is delivered locally.
> This patch should fix it.
Ha! You got it. Nice.
Looks like I can finally move on trying to upgrade my kernel...
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 23:24 ` Christophe Saout
@ 2006-01-29 23:26 ` Patrick McHardy
2006-01-29 23:29 ` Patrick McHardy
2006-01-29 23:30 ` Christophe Saout
0 siblings, 2 replies; 14+ messages in thread
From: Patrick McHardy @ 2006-01-29 23:26 UTC (permalink / raw)
To: Christophe Saout; +Cc: netfilter-devel, Herbert Xu
Christophe Saout wrote:
> Am Sonntag, den 29.01.2006, 23:59 +0100 schrieb Patrick McHardy:
>
>
>>Found it, the packet doesn't have its dst_entry released after DNAT in
>>PRE_ROUTING because of an incorrect check and is delivered locally.
>>This patch should fix it.
>
>
> Ha! You got it. Nice.
>
> Looks like I can finally move on trying to upgrade my kernel...
Actually it seems I got confused, the check looks right. Can you post
the output of /proc/net/ip_conntrack for this connection please?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 23:26 ` Patrick McHardy
@ 2006-01-29 23:29 ` Patrick McHardy
2006-01-29 23:30 ` Christophe Saout
1 sibling, 0 replies; 14+ messages in thread
From: Patrick McHardy @ 2006-01-29 23:29 UTC (permalink / raw)
To: Christophe Saout; +Cc: netfilter-devel, Herbert Xu
Patrick McHardy wrote:
> Christophe Saout wrote:
>
>>Looks like I can finally move on trying to upgrade my kernel...
>
>
> Actually it seems I got confused, the check looks right. Can you post
> the output of /proc/net/ip_conntrack for this connection please?
Seems like I'm too tired to think, I was looking at the already
patched kernel when making that statement :) The patch is indeed
correct.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 23:26 ` Patrick McHardy
2006-01-29 23:29 ` Patrick McHardy
@ 2006-01-29 23:30 ` Christophe Saout
1 sibling, 0 replies; 14+ messages in thread
From: Christophe Saout @ 2006-01-29 23:30 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
Am Montag, den 30.01.2006, 00:26 +0100 schrieb Patrick McHardy:
> >>Found it, the packet doesn't have its dst_entry released after DNAT in
> >>PRE_ROUTING because of an incorrect check and is delivered locally.
> >>This patch should fix it.
>
> Actually it seems I got confused, the check looks right. Can you post
> the output of /proc/net/ip_conntrack for this connection please?
tcp 6 431980 ESTABLISHED src=192.168.80.90 dst=<inet host>
sport=33816 dport=22 packets=22 bytes=3972 src=<inet host> dst=<gateway
pub ip> sport=22 dport=33816 packets=19 bytes=3568 [ASSURED] mark=0
use=1
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-01-29 22:59 ` Patrick McHardy
2006-01-29 23:24 ` Christophe Saout
@ 2006-02-03 1:16 ` David S. Miller
2006-02-03 10:24 ` Patrick McHardy
1 sibling, 1 reply; 14+ messages in thread
From: David S. Miller @ 2006-02-03 1:16 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, herbert
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 29 Jan 2006 23:59:24 +0100
> Found it, the packet doesn't have its dst_entry released after DNAT in
> PRE_ROUTING because of an incorrect check and is delivered locally.
> This patch should fix it.
Patrick, want me to apply this?
I need a changelog and signed-off-by line if so.
Thanks.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.16-rc1-mm3 XFRM+NAT issue
2006-02-03 1:16 ` David S. Miller
@ 2006-02-03 10:24 ` Patrick McHardy
0 siblings, 0 replies; 14+ messages in thread
From: Patrick McHardy @ 2006-02-03 10:24 UTC (permalink / raw)
To: David S. Miller; +Cc: netfilter-devel, herbert
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Sun, 29 Jan 2006 23:59:24 +0100
>
>
>>Found it, the packet doesn't have its dst_entry released after DNAT in
>>PRE_ROUTING because of an incorrect check and is delivered locally.
>>This patch should fix it.
>
>
> Patrick, want me to apply this?
>
> I need a changelog and signed-off-by line if so.
Please wait, I've planned to submit this with a bunch of other
fixes tonight or tommorrow.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-02-03 10:24 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-29 19:41 2.6.16-rc1-mm3 XFRM+NAT issue Christophe Saout
2006-01-29 19:57 ` Patrick McHardy
2006-01-29 20:59 ` Christophe Saout
2006-01-29 22:14 ` Patrick McHardy
2006-01-29 22:30 ` Christophe Saout
2006-01-29 22:43 ` Patrick McHardy
2006-01-29 23:11 ` Christophe Saout
2006-01-29 22:59 ` Patrick McHardy
2006-01-29 23:24 ` Christophe Saout
2006-01-29 23:26 ` Patrick McHardy
2006-01-29 23:29 ` Patrick McHardy
2006-01-29 23:30 ` Christophe Saout
2006-02-03 1:16 ` David S. Miller
2006-02-03 10:24 ` Patrick McHardy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.