FORWARD packet problem

FORWARD packet problem

[Paulo Andre]

I have a multiple isp fw
eth0 = int
eth1 = default isp
eth2 = sec isp

when I try and make a connection to and internal server via the eth2 , 
the packet appears on the PREROUTING table, and then not on FORWARD , 
anyone have any ideas?

Paulo

Re: FORWARD packet problem

[Jorge Davila]

There is no so much information to get an answer.

What is your routing table information?

What are your firewall rules?

I'm guessing a routing problem or missed firewall rules.

Jorge.

El mié, 19-07-2006 a las 17:12 +0200, Paulo Andre escribió:
> I have a multiple isp fw
> eth0 = int
> eth1 = default isp
> eth2 = sec isp
> 
> when I try and make a connection to and internal server via the eth2 , 
> the packet appears on the PREROUTING table, and then not on FORWARD , 
> anyone have any ideas?
> 
> Paulo
> 
-- 
Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 808 2478
davila@nicaraguaopensource.com

Re: FORWARD packet problem

[Pascal Hambourg]

Hello,

Paulo Andre a écrit :
> I have a multiple isp fw
> eth0 = int
> eth1 = default isp
> eth2 = sec isp
> 
> when I try and make a connection to and internal server via the eth2 , 
> the packet appears on the PREROUTING table, and then not on FORWARD , 
> anyone have any ideas?

I guess there is a default route via eth1.
If so, first check that /proc/sys/net/ipv4/conf/eth2/rp_filter=0 else 
the input routing, which takes place between PREROUTING and INPUT or 
FORWARD, may drop incoming IP packets on eth2 whose source address is 
not routed out via eth2 as a protection against IP spoofing.

Re: FORWARD packet problem

[Paulo Andre]

Pascal Hambourg wrote:

> Hello,
>
> Paulo Andre a écrit :
>
>> I have a multiple isp fw
>> eth0 = int
>> eth1 = default isp
>> eth2 = sec isp
>>
>> when I try and make a connection to and internal server via the eth2 
>> , the packet appears on the PREROUTING table, and then not on FORWARD 
>> , anyone have any ideas?
>
>
> I guess there is a default route via eth1.
> If so, first check that /proc/sys/net/ipv4/conf/eth2/rp_filter=0 else 
> the input routing, which takes place between PREROUTING and INPUT or 
> FORWARD, may drop incoming IP packets on eth2 whose source address is 
> not routed out via eth2 as a protection against IP spoofing.
>
>
Thanks Pascal, that fixed it.
Would I have to use CONNMARK and MARK to get connections leaving the 
correct interface?

Paulo

Re: FORWARD packet problem

[Pascal Hambourg]

Paulo Andre a écrit :
>>
>>> I have a multiple isp fw
>>> eth0 = int
>>> eth1 = default isp
>>> eth2 = sec isp
>>>
>>> when I try and make a connection to and internal server via the eth2 
>>> , the packet appears on the PREROUTING table, and then not on FORWARD 
>>> , anyone have any ideas?

[disable rp_filter on the interface]

> Thanks Pascal, that fixed it.

Be aware that now eth2 is not protected against IP spoofing by the input 
routing any more. So you must use iptables rules to drop incoming 
packets with an "impossible" IP source address on this interface, i.e. 
an address belonging to another interface (lo, eth0, eth1) subnet.

> Would I have to use CONNMARK and MARK to get connections leaving the 
> correct interface?

I'm not sure I understand your question correctly. Do you mean routing 
reply packets belonging to connections coming from the secondary ISP 
back through the same interface ?

If so, you have to use CONNMARK+MARK+advanced routing only when there is 
no other way to identify packets which must be sent via the non-default 
interface. If they have distinctive characteristics other than the 
source or destination IP addresses (for example the source or 
destination port), you don't need CONNMARK and can use only 
MARK+advanced routing. If they have distinctive source IP addresses, you 
can use only advanced routing. And of course, if they have distinctive 
destination IP addresses, you only need standard routing.

But routing the packets through the correct interface won't allow you to 
re-enable rp_filter, at least when MARK is in use, because the rp_filter 
validation does not take iptables rules into account. I'm not sure about 
using only advanced routing though (does rp_filter validation use the 
packet destination address ?).