* Re: NAT Issue
@ 2007-04-20 11:08 Kiran Murari
2007-04-20 11:25 ` Yasuyuki KOZAKAI
[not found] ` <200704201125.l3KBPGSw018412@toshiba.co.jp>
0 siblings, 2 replies; 7+ messages in thread
From: Kiran Murari @ 2007-04-20 11:08 UTC (permalink / raw)
To: netfilter
Hi,
> >
> > My setup is as shown below.
> > PC--------Router---------ISP
> >
> > I established a connection with the ISP (PPP link) and I am pinging
> > google.com from LAN side host.
> > Now if I disable WAN
>
What do you mean exactly ?
I have an option of enabling/disabling the WAN interface from the WEB interface of the Router.
> > (leave the ping running) and then enable it, the
> > session does not resume.
>
What session ?
The PING session which was running earlier, does not resume after my WAN is up
> > The SNAT rules are in place.
> > # iptables -t nat -L POSTROUTING -n -v
> > Chain POSTROUTING (policy ACCEPT 13927 packets, 458K bytes)
> > pkts bytes target prot opt in out source destination
> > 0 0 SNAT all -- * ppp0 0.0.0.0/0
> > 0.0.0.0/0 to:xx:xx:xx:xx
>
Is the public address fixed or can it change at each PPP connection ?
The public IP can be configured for both static and dynamic addresses.
> > # cat /proc/net/ip_conntrack | grep icmp
> > icmp 1 29 src=yy:yy:yy:yy dst=64.233.167.99 type=8 code=0 id=16446
> > packets=575 bytes=48300 [UNREPLIED]
> > src=yy:yy:yy:yy dst=192.168.10.100 type=0 code=0 id=16446 packets=0
> > bytes=0 mark=0 use=1
> > yy:yy:yy:yy being the IP address of the LAN host.
>
I doubt that the source address of the expected reply is the LAN host
address. What is 192.168.10.100 ?
It's my mistake in putting the conntrack entry.... :(
The correct entry is
# cat /proc/net/ip_conntrack | grep icmp
icmp 1 29 src=yy:yy:yy:yy dst=64.233.167.99 type=8 code=0 id=16446
packets=575 bytes=48300 [UNREPLIED]
src=64.233.167.99 dst=yy:yy:yy:yy type=0 code=0 id=16446 packets=0
bytes=0 mark=0 use=1
yy:yy:yy:yy being the IP address of the LAN host.
After little bit of experimenting, I could see that if I flush all the conntrack entries,
as soon as my WAN is enabled, the PING session continued.
But flushing all the conntrack entries, doesn't look like a feasible one.
Is there a way to flush the conntrack entries that have been created during a specific interval.
Any thoughts.
Thanks,
Kiran
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT Issue
2007-04-20 11:08 NAT Issue Kiran Murari
@ 2007-04-20 11:25 ` Yasuyuki KOZAKAI
[not found] ` <200704201125.l3KBPGSw018412@toshiba.co.jp>
1 sibling, 0 replies; 7+ messages in thread
From: Yasuyuki KOZAKAI @ 2007-04-20 11:25 UTC (permalink / raw)
To: kmurari; +Cc: netfilter
From: Kiran Murari <kmurari@embeddedinfotech.com>
Date: Fri, 20 Apr 2007 16:38:32 +0530
> After little bit of experimenting, I could see that if I flush all the conntrack entries,
> as soon as my WAN is enabled, the PING session continued.
>
> But flushing all the conntrack entries, doesn't look like a feasible one.
>
> Is there a way to flush the conntrack entries that have been created during a specific interval.
>
> Any thoughts.
Why don't you flush table with tool 'conntrack' just after bringing up your
WAN ?
http://www.netfilter.org/projects/conntrack/index.html
-- Yasuyuki Kozakai
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT Issue
[not found] ` <200704201125.l3KBPGSw018412@toshiba.co.jp>
@ 2007-04-20 12:09 ` Kiran Murari
2007-04-20 12:21 ` Yasuyuki KOZAKAI
2007-04-20 20:54 ` Nagy Zoltan
0 siblings, 2 replies; 7+ messages in thread
From: Kiran Murari @ 2007-04-20 12:09 UTC (permalink / raw)
To: Yasuyuki KOZAKAI; +Cc: netfilter
Yasuyuki KOZAKAI wrote:
> From: Kiran Murari <kmurari@embeddedinfotech.com>
> Date: Fri, 20 Apr 2007 16:38:32 +0530
>
>
>> After little bit of experimenting, I could see that if I flush all the conntrack entries,
>> as soon as my WAN is enabled, the PING session continued.
>>
>> But flushing all the conntrack entries, doesn't look like a feasible one.
>>
>> Is there a way to flush the conntrack entries that have been created during a specific interval.
>>
>> Any thoughts.
>>
>
> Why don't you flush table with tool 'conntrack' just after bringing up your
> WAN ?
>
> http://www.netfilter.org/projects/conntrack/index.html
>
> -- Yasuyuki Kozakai
>
Yeah I have seen the 'conntrack'.
But this requires linnetfilter_conntrack and libnfnetlink support.
I am running a 2.6.14 on an Xscale processor.
So is there a means to flush the entries, other than porting the
'conntrack' to Xscale.
- Kiran
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT Issue
2007-04-20 12:09 ` Kiran Murari
@ 2007-04-20 12:21 ` Yasuyuki KOZAKAI
2007-04-20 20:54 ` Nagy Zoltan
1 sibling, 0 replies; 7+ messages in thread
From: Yasuyuki KOZAKAI @ 2007-04-20 12:21 UTC (permalink / raw)
To: kmurari; +Cc: netfilter
From: Kiran Murari <kmurari@embeddedinfotech.com>
Date: Fri, 20 Apr 2007 17:39:21 +0530
> Yasuyuki KOZAKAI wrote:
> > From: Kiran Murari <kmurari@embeddedinfotech.com>
> > Date: Fri, 20 Apr 2007 16:38:32 +0530
> >
> >
> >> After little bit of experimenting, I could see that if I flush all the conntrack entries,
> >> as soon as my WAN is enabled, the PING session continued.
> >>
> >> But flushing all the conntrack entries, doesn't look like a feasible one.
> >>
> >> Is there a way to flush the conntrack entries that have been created during a specific interval.
> >>
> >> Any thoughts.
> >>
> >
> > Why don't you flush table with tool 'conntrack' just after bringing up your
> > WAN ?
> >
> > http://www.netfilter.org/projects/conntrack/index.html
> >
> > -- Yasuyuki Kozakai
> >
> Yeah I have seen the 'conntrack'.
> But this requires linnetfilter_conntrack and libnfnetlink support.
> I am running a 2.6.14 on an Xscale processor.
>
> So is there a means to flush the entries, other than porting the
> 'conntrack' to Xscale.
There is no way. Other solution in my mind is to set a filter rule
to drop all forwarded packets, just before bringing down WAN interface.
-- Yasuyuki Kozakai
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT Issue
2007-04-20 12:09 ` Kiran Murari
2007-04-20 12:21 ` Yasuyuki KOZAKAI
@ 2007-04-20 20:54 ` Nagy Zoltan
1 sibling, 0 replies; 7+ messages in thread
From: Nagy Zoltan @ 2007-04-20 20:54 UTC (permalink / raw)
To: netfilter
Kiran Murari wrote:
>>>
>>> Is there a way to flush the conntrack entries that have been created
>>> during a specific interval.
>>
>> -- Yasuyuki Kozakai
>>
> Yeah I have seen the 'conntrack'.
> But this requires linnetfilter_conntrack and libnfnetlink support.
> I am running a 2.6.14 on an Xscale processor.
>
> So is there a means to flush the entries, other than porting the
> 'conntrack' to Xscale.
>
> - Kiran
>
>
i've just a minimal coding experience with conntrack,
but i think you need something like 'removing conntrack entries which
routes are invalid' - as a kernel level feature - i think in this case
when the wan interface is down you dont have a valid default route...so
the logic would match on it - and remove them
i think this can be implemented and it would be logical to remove
invalid routes from the conntrack anyway - i've tried on my
desktop(2.6.19-gentoo-r5) and it won't removed anything
kirk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT Issue
2007-04-19 10:09 Kiran Murari
@ 2007-04-19 22:24 ` Pascal Hambourg
0 siblings, 0 replies; 7+ messages in thread
From: Pascal Hambourg @ 2007-04-19 22:24 UTC (permalink / raw)
To: netfilter
Hello,
Kiran Murari a écrit :
>
> My setup is as shown below.
> PC--------Router---------ISP
>
> I established a connection with the ISP (PPP link) and I am pinging
> google.com from LAN side host.
> Now if I disable WAN
What do you mean exactly ?
> (leave the ping running) and then enable it, the
> session does not resume.
What session ?
> The SNAT rules are in place.
> # iptables -t nat -L POSTROUTING -n -v
> Chain POSTROUTING (policy ACCEPT 13927 packets, 458K bytes)
> pkts bytes target prot opt in out source destination
> 0 0 SNAT all -- * ppp0 0.0.0.0/0
> 0.0.0.0/0 to:xx:xx:xx:xx
Is the public address fixed or can it change at each PPP connection ?
> # cat /proc/net/ip_conntrack | grep icmp
> icmp 1 29 src=yy:yy:yy:yy dst=64.233.167.99 type=8 code=0 id=16446
> packets=575 bytes=48300 [UNREPLIED]
> src=yy:yy:yy:yy dst=192.168.10.100 type=0 code=0 id=16446 packets=0
> bytes=0 mark=0 use=1
> yy:yy:yy:yy being the IP address of the LAN host.
I doubt that the source address of the expected reply is the LAN host
address. What is 192.168.10.100 ?
^ permalink raw reply [flat|nested] 7+ messages in thread
* NAT Issue
@ 2007-04-19 10:09 Kiran Murari
2007-04-19 22:24 ` Pascal Hambourg
0 siblings, 1 reply; 7+ messages in thread
From: Kiran Murari @ 2007-04-19 10:09 UTC (permalink / raw)
To: netfilter
Hi All,
I am facing an issue related to NAT.
My setup is as shown below.
PC--------Router---------ISP
I established a connection with the ISP (PPP link) and I am pinging
google.com from LAN side host.
Now if I disable WAN (leave the ping running) and then enable it, the
session does not resume.
Moreover, packet capture on the WAN interface shows LAN host address,
but not the WAN IP.
The SNAT rules are in place.
# iptables -t nat -L POSTROUTING -n -v
Chain POSTROUTING (policy ACCEPT 13927 packets, 458K bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * ppp0 0.0.0.0/0
0.0.0.0/0 to:xx:xx:xx:xx
0 0 SNAT all -- * * 0.0.0.0/0
0.0.0.0/0 MARK match 0x1111 to:zz:zz:zz:zz
ip_conntrack shows the following entry:
# cat /proc/net/ip_conntrack | grep icmp
icmp 1 29 src=yy:yy:yy:yy dst=64.233.167.99 type=8 code=0 id=16446
packets=575 bytes=48300 [UNREPLIED]
src=yy:yy:yy:yy dst=192.168.10.100 type=0 code=0 id=16446 packets=0
bytes=0 mark=0 use=1
yy:yy:yy:yy being the IP address of the LAN host.
But if I kill the ping session and start a new session, this gets NAT'ed
properly.
Couldn't understand why the running session does not resume after the
WAN is enabled.
Any help in this aspect is highly appreciated.
Best Regards,
Kiran
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-04-20 20:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-20 11:08 NAT Issue Kiran Murari
2007-04-20 11:25 ` Yasuyuki KOZAKAI
[not found] ` <200704201125.l3KBPGSw018412@toshiba.co.jp>
2007-04-20 12:09 ` Kiran Murari
2007-04-20 12:21 ` Yasuyuki KOZAKAI
2007-04-20 20:54 ` Nagy Zoltan
-- strict thread matches above, loose matches on Subject: below --
2007-04-19 10:09 Kiran Murari
2007-04-19 22:24 ` Pascal Hambourg
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.