Skip to contentSkip to conversation

NAT Issue

DISCUSSION Kiran Murari 3 participants 5 messages Apr 20, 2007 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

Hi,

Quoted 7 lines
Quoted 6 lines

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.

Quoted 2 lines
Quoted 1 line

(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

Quoted 7 lines
Quoted 6 lines

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.

Quoted 5 lines
Quoted 4 lines
# 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

#1 lore raw

From: Kiran Murari <[email protected]>
Date: Fri, 20 Apr 2007 16:38:32 +0530

Quoted 8 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw
Quoted 14 lines · Yasuyuki KOZAKAI

From: Kiran Murari <[email protected]>
Date: Fri, 20 Apr 2007 16:38:32 +0530

Quoted 9 lines

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.

Quoted 7 lines

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

#4 lore raw

From: Kiran Murari <[email protected]>
Date: Fri, 20 Apr 2007 17:39:21 +0530

Quoted 20 lines
Quoted 19 lines · Yasuyuki KOZAKAI

From: Kiran Murari <[email protected]>
Date: Fri, 20 Apr 2007 16:38:32 +0530

Quoted 9 lines

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

Quoted 8 lines
Quoted 2 lines

-- 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

#5 lore raw
In reply to Kiran Murari
Quoted 5 lines · Kiran Murari
Quoted 5 lines
Quoted 2 lines

Is there a way to flush the conntrack entries that have been created during a specific interval.

-- Yasuyuki Kozakai

Quoted 9 lines

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