Re: NAT Issue

Re: NAT Issue

[Kiran Murari]

  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

Re: NAT Issue

[Yasuyuki KOZAKAI]

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

Re: NAT Issue

[Kiran Murari]

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

Re: NAT Issue

[Yasuyuki KOZAKAI]

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

Re: NAT Issue

[Nagy Zoltan]

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

NAT Issue

[Kiran Murari]

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

Re: NAT Issue

[Pascal Hambourg]

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 ?