[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: ipf redirection feature functional on Solaris 10?
From:       Dominique Petitpierre <Dominique.Petitpierre () unige ! ch>
Date:       2009-10-01 16:45:52
Message-ID: 21664_1254416159_4AC4DF1E_21664_4723_1_4AC4DCC0.8030501 () unige ! ch
[Download RAW message or body]


I wrote:

> If it matters, this is occuring in a Solaris 10 zone, whith virtual
> interfaces one of which uses 801.q tagging (vlan 305, subnet
> 10.13.5.0/24),

well, it turns out that 802.1q tagging does matter: packets redirected
by an ipf policy based routing rule to an interface with tagging are
not transmitted.


In order to better see what was happening the ipf rules were extended
like this (stateless case):

@1 pass in quick on e1000g0 proto tcp from any to any port = 443 group i_sso-test1
@2 pass in quick on e1000g305000 proto tcp from any to any port = 443 group \
i_sso-test1

@1 pass out quick on e1000g0 to e1000g305000:10.13.5.1 proto tcp from 10.13.5.181/32 \
port = 443 to any group o_sso-test1 @2 pass out quick on e1000g305000 to \
e1000g0:10.194.7.1 proto tcp from 10.194.7.81/32 port = 443 to any group o_sso-test1 \
@3 pass out quick on e1000g305000 proto tcp from any port = 443 to any group \
o_sso-test1 @4 pass out quick on e1000g0 proto tcp from any port = 443 to any group \
o_sso-test1

Also, for the purpose of the demonstration, the zone configuration was
modified to direct all packets to the same interface with tagging,
thus having just one default route:

zonecfg -z sso-test1 info net
net:
        address: 10.13.5.181/24
        physical: e1000g305000
        defrouter: 10.13.5.1
net:
        address: 10.194.7.81/24
        physical: e1000g305000
        defrouter: 10.13.5.1

netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface 
-------------------- -------------------- ----- ----- ---------- --------- 
default              10.194.7.1           UG        1       2867           
default              10.13.5.1            UG        1         86 e1000g305000 
10.13.5.0            10.13.5.181          U         1          2 e1000g305000:1 
10.194.7.0           10.194.7.81          U         1          0 e1000g305000:3 
224.0.0.0            10.13.5.181          U         1          0 e1000g305000:1 
127.0.0.1            127.0.0.1            UH        1          7 lo0:7     

(In this peculiar case the default route to 10.194.7.1 is an artifact
displayed by netstat due to the zone isolation mechanism, but it is
not actually used for routing at the zone level; the interface without
tagging, e1000g0, is only displayed on the global zone where ipfilter
operates)

When testing from 10.194.17.11 with "telnet 10.13.4.180 443", it
works. And one can see in the ipf logs that it is the third out rule
that matched (@o_sso-test1:3), i.e. there was no redirection on
another interface (proof that there is nothing wrong with the context
setup):

 16:59:30.479660 e1000g305000 @i_sso-test1:2 p 10.194.17.11,2111 -> 10.13.5.181,443 \
PR tcp len 20 60 -S IN  16:59:30.479844 e1000g305000 @o_sso-test1:3 p 10.13.5.181,443 \
-> 10.194.17.11,2111 PR tcp len 20 44 -AS OUT  16:59:30.480182 e1000g305000 \
@i_sso-test1:2 p 10.194.17.11,2111 -> 10.13.5.181,443 PR tcp len 20 40 -A IN

When testing from 10.194.17.11 with "telnet 10.194.7.81 443", it works
also. This time one can see in the ipf logs that it is the second out
rule that matched (@o_sso-test1:2), i.e. there was redirection from
e1000g305000 to e1000g0.

 16:59:41.247101 e1000g0 @i_sso-test1:1 p 10.194.17.11,3851 -> 10.194.7.81,443 PR tcp \
len 20 60 -S IN  16:59:41.247206 e1000g305000 @o_sso-test1:2 p 10.194.7.81,443 -> \
10.194.17.11,3851 PR tcp len 20 64 -AS OUT  16:59:41.247508 e1000g0 @i_sso-test1:1 p \
10.194.17.11,3851 -> 10.194.7.81,443 PR tcp len 20 52 -A IN

A packet capture confirms this and one can see in the capture the
SYN-ACK reply packet go out on e1000g0.

The reverse case, essentially the original setup shown in my first
post, where the default route is the interface without tagging
(e1000g0) and the reply packet matches the redirection rule from
e1000g0 to the interface with tagging e1000g305000, the packet is lost
(i.e. is not visible in the packet capture on either interface).

Further tests with stateful redirection ("reply-to") show the same
pattern (does not work when packets are redirected to an interface
with tagging).


It looks like it is a bug: may be ipfilter injects the redirected
packet at a processing stage where it should already have a 802.1q tag
but does not, or something similar; in the working case, ipfilter acts
on a not yet tagged packet which can be used "as is" at the same
processing stage on the non tagging interface, and thus is correctly
transmitted.



Conclusion: ipfilter policy based routing does work on Solaris 10u7,
but, at least in my setup, not when redirection occurs to a 802.1q
tagging interface.

- Could somebody confirm this?
- Is this a known bug? (I didn't find anything relevant on sunsolve or
  on the ipfilter mailing list)


Best regards,
Dominique

Mr Dominique Petitpierre       Email: User@Domain
Division Informatique                 User=Dominique.Petitpierre
University of Geneva                  Domain=unige.ch


[prev in list] [next in list] [prev in thread] [next in thread]