FW: CONNMARK and ip rule fwmark

FW: CONNMARK and ip rule fwmark

[Steffen Heil]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

Sorry, I am not accustomed yet to not having reply-to the list... 

> -----Original Message-----
> From: Steffen Heil [mailto:lists@steffen-heil.de] 
> Sent: Monday, March 31, 2008 2:07 AM
> To: 'Jan Engelhardt'
> Subject: RE: CONNMARK and ip rule fwmark
> 
> Hi
> 
> > ># iptables -t nat -A PREROUTING -p TCP -d publicip -j DNAT --to
> > >10.4.0.1
> > >
> > >My observations seem to tell me, that ip rule is evaluated BEFORE 
> > >iptables rules are applied, so the mark is not set yet.
> > 
> > See http://jengelh.hopto.org/images/nf-packet-flow.png , routing 
> > decision takes place in the middle. (It's called _PRE_ROUTING_ for a
> > reason.)
> 
> Can you think of any reason SYN ACK packets are not seen at 
> ANY tables in my case?
> I see the syn packet and I know the service is running at that port!
> a.b.c.d is the client.
> 
> Regards,
>   Steffen
> 
> 
> 
> iptables -t raw -I PREROUTING -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t raw -I OUTPUT -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t raw -I PREROUTING -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t raw -I OUTPUT -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t filter -I INPUT -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t filter -I FORWARD -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t filter -I OUTPUT -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t filter -I INPUT -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t filter -I FORWARD -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t filter -I OUTPUT -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t nat -I PREROUTING -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t nat -I POSTROUTING -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t nat -I OUTPUT -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t nat -I PREROUTING -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t nat -I POSTROUTING -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t nat -I OUTPUT -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t mangle -I PREROUTING -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t mangle -I INPUT -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t mangle -I FORWARD -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t mangle -I OUTPUT -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t mangle -I POSTROUTING -p tcp -d a.b.c.d/24 -j LOG 
> iptables -t mangle -I PREROUTING -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t mangle -I INPUT -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t mangle -I FORWARD -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t mangle -I OUTPUT -p tcp -s a.b.c.d/24 -j LOG 
> iptables -t mangle -I POSTROUTING -p tcp -s a.b.c.d/24 -j LOG
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3109 bytes --]

Re: FW: CONNMARK and ip rule fwmark

[Grant Taylor]

On 3/31/2008 2:07 AM, Steffen Heil wrote:
> Can you think of any reason SYN ACK packets are not seen at ANY
> tables in my case?  I see the syn packet and I know the service is
> running at that port!

What are the following files set to on your system?

/proc/sys/net/ipv4/conf/*/rp_filter
/proc/sys/net/ipv4/ip_forward
/proc/sys/net/ipv4/conf/*/log_martians

The more I think about what you are seeing, packets come in to your 
system but not make it to IPTables, the more I think that reverse path 
filter is on (set to 1) and filtering out the packets that you are 
trying to work with.

Consider the configuration below:

            +---+
            | C |
            +-+-+
              :
              :
+---+                 +---+
|   +- -     x     - -+   |
+-+-+                 +-+-+
   a                     b
   D                     D
   |                     |
   e                     e
   A                     B
+-+-+                 +-+-+
| A +-oA-(OpenVPN)-oB-+ B |
+---+                 +---+

When client C connects to eB, which is port forwarded to oA, A will see 
the traffic as being from C to oA.  A would route traffic to C out via 
eA, not oA.  If Reverse Path Filtering (a.k.a. RPF) (rp_filter) is 
turned on (set to 1) then the kernel on A will drop the traffic as it is 
coming in to the system as a martian.  If RPF is not turned on (set to 
0) then the kernel will route the packets with out any regard to the 
source / destination IP address.

I'd suggest that you enable logging of martians (set log_martians to 1) 
and check the syslog for reports of martians / dropped packets.



Grant. . . .