Something weird

Something weird

[Marcio Veloso Antunes]

Hi people,

  I'm asking for help because i'm getting crazy. :)

  I have PPPoE connection Up, all my traffic is correctly masqueraded BUT an specific route is not being masqueraded, look:

root@fw:/etc/ppp# iptables -L -nv -t nat
...
Chain POSTROUTING (policy ACCEPT 1759 packets, 154K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      ppp0    172.18.0.128/28      0.0.0.0/0
   54  4477 MASQUERADE  all  --  *      ppp0    172.18.0.0/24        0.0.0.0/0

root@fw:/etc/ppp# tcpdump -i ppp0 -n port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
08:24:04.072325 IP 172.18.0.13.5060 > 200.198.184.204.5060: SIP, length: 422
08:24:06.076677 IP 172.18.0.13.5060 > 200.198.184.204.5060: SIP, length: 422

My route table is:
root@fw:/etc/ppp# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
200.198.184.204 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
200.222.117.82  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.8.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
200.198.184.196 10.8.0.1        255.255.255.252 UG    0      0        0 tun0
200.198.184.200 10.8.0.1        255.255.255.248 UG    0      0        0 tun0
172.18.2.128    0.0.0.0         255.255.255.240 U     0      0        0 eth0
172.18.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.18.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.25.0.0      10.8.0.1        255.255.255.0   UG    0      0        0 tun0
172.21.0.0      10.8.0.1        255.255.255.0   UG    0      0        0 tun0
172.20.0.0      10.8.0.1        255.255.0.0     UG    0      0        0 tun0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

and my masquerade config is:
...
IPTABLES="/usr/sbin/iptables"
EXT="ppp0"
NET_INTERNA="172.18.0.0/24"
...
$IPTABLES -t nat -A POSTROUTING -o $EXT -s $NET_INTERNA                -j MASQUERADE

Can you bring me some light on why packets from 172.18.0.13 are crossing ppp0 whithout being masqueraded ?
I am lost.

Thanks a lot,

-- 
Marcio Veloso Antunes
Tecnologia IP Ltda
+55.21.3005.3004
+55.11.3588.0802
+55.21.8539.2949

Re: Something weird

[Grant Taylor]

On 10/01/08 06:34, Marcio Veloso Antunes wrote:
> Can you bring me some light on why packets from 172.18.0.13 are 
> crossing ppp0 whithout being masqueraded?

I can't tell for sure (you did not provide your IP addresses per say) 
but it looks like the traffic is from your internal network and headed 
for your external ppp0 interface its self.

Seeing as how you did not actually provide your IPs I'm guessing based 
on the fact that you have a route of 200.198.184.204/32 on your ppp0 
interface that said IP is bound to said interface.  If this is the case, 
it is possible that the traffic is entering the kernel and going up the 
network stack directly rather than being forwarded like you would expect.

I believe this is coming back to the fact that IPs are not bound to an 
interface per say, but rather the computer and that in some situations 
any interface in the system will take the traffic and pass it up in to 
the network with out forwarding it over to the interface that it is 
bound to before it takes the traffic and passes it higher in the 
networking stack.



Grant. . . .

Re: Something weird

[Marcio Veloso Antunes]

Grant,

  I found out what is happening, it is exactly what you've said.

  The reason this occurs is related to conntrack, the specific route is getting up after 
the first packet leaves the internal network (via VPN interface, without masquerade), then 
when the specific route enters, the connection has been established already.

  Even when the interface changes from TUN0 to PPP0 the connection persists and the packets 
keep NOT being re-verified.

  I don't know if it can be considered a Bug, but it seems to me an odd situation as the interface 
have changed, other networks will be crossed, i think the rules should be re-validated, don't you ?

root@fw:/proc/net# grep 172.18.0.13 ip_conntrack
udp      17 2809 src=172.18.0.13 dst=200.198.184.204 sport=5060 dport=5060 packets=977 bytes=537937 src=200.198.184.204 dst=172.18.0.13 sport=5060 dport=5060 packets=30 bytes=16384 
[ASSURED] mark=0 use=1

  Thanks for your help,

Em Quarta 01 Outubro 2008, você escreveu:
> On 10/01/08 06:34, Marcio Veloso Antunes wrote:
> > Can you bring me some light on why packets from 172.18.0.13 are
> > crossing ppp0 whithout being masqueraded?
>
> I can't tell for sure (you did not provide your IP addresses per say)
> but it looks like the traffic is from your internal network and headed
> for your external ppp0 interface its self.
>
> Seeing as how you did not actually provide your IPs I'm guessing based
> on the fact that you have a route of 200.198.184.204/32 on your ppp0
> interface that said IP is bound to said interface.  If this is the case,
> it is possible that the traffic is entering the kernel and going up the
> network stack directly rather than being forwarded like you would expect.
>
> I believe this is coming back to the fact that IPs are not bound to an
> interface per say, but rather the computer and that in some situations
> any interface in the system will take the traffic and pass it up in to
> the network with out forwarding it over to the interface that it is
> bound to before it takes the traffic and passes it higher in the
> networking stack.
>
>
>
> Grant. . . .
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Marcio Veloso Antunes
Tecnologia IP Ltda
+55.21.3005.3004
+55.11.3588.0802
+55.21.8539.2949

Re: Something weird

[Grant Taylor]

On 10/01/08 09:51, Marcio Veloso Antunes wrote:
> I found out what is happening, it is exactly what you've said.

*nod*

> The reason this occurs is related to conntrack, the specific route is 
> getting up after the first packet leaves the internal network (via 
> VPN interface, without masquerade), then when the specific route 
> enters, the connection has been established already.

That will do it.

> Even when the interface changes from TUN0 to PPP0 the connection 
> persists and the packets keep NOT being re-verified.

'k

> I don't know if it can be considered a Bug, but it seems to me an odd 
> situation as the interface have changed, other networks will be 
> crossed, i think the rules should be re-validated, don't you ?

I don't know if it is a bug per say or not.  I would guess it has to do 
with whether or not the connection tracking code in kernel is aware of 
interface / network / route state changes or not.  If it is unaware of 
state changes then it is not possible for connection tracking to know 
that something is amiss.  If it is aware of state change then I would 
think that it should trap for this and handle it more gracefully than it 
did, thus a possible bug.  But seeing as how I don't get that deep in to 
kernel I can't say one way or the other.

> root@fw:/proc/net# grep 172.18.0.13 ip_conntrack
> udp      17 2809 src=172.18.0.13 dst=200.198.184.204 sport=5060 
> dport=5060 packets=977 bytes=537937 src=200.198.184.204 
> dst=172.18.0.13 sport=5060 dport=5060 packets=30 bytes=16384 
> [ASSURED] mark=0 use=1

Would it be possible to DROP the traffic before the VPN comes up such 
that the connection would never be successfully established and then 
allow the traffic once the VPN is up?  Hopefully this would allow 
connection tracking to track the traffic on the proper interface.  Also, 
make sure you use a DROP not a REJECT as you don't want to return an 
error the the client application(s) thus causing them to give up rather 
than timing out and re-trying like they would if the traffic was just 
DROPed and lost in the ether.

> Thanks for your help,

If you consider a direction to look with out an answer help, you are 
welcome.  ;)



Grant. . . .