[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 () unige ! ch
Date:       2009-11-14 2:10:58
Message-ID: 18225_1258165462_4AFE14D5_18225_9004_1_20091114031058.t23xnkotsosos4g4 () webmail ! unige ! ch
[Download RAW message or body]

Hello,

Thanks for your reply:

Quoting Darren Reed <darrenr@reed.wattle.id.au>:

> ...

> | It does not work either; in the ipf log it shows that both the in and
> | the first out rules matched:
> |
> | 23:09:00.591163 e1000g305000 @i_sso-test1:1 p 10.194.17.11,26080 ->
> 10.13.5.181,443 PR tcp len 20 60 -S IN
> | 23:09:00.591363 e1000g0 @o_sso-test1:1 p 10.13.5.181,443 ->
> 10.194.17.11,26080 PR tcp len 20 44 -AS OUT
>
> These are two different packets...

Yes: the incoming TCP SYN and the outgoing reply TCP SYN ACK.  The
problem is while a snooping utility sees the incoming packet on
e1000g305000, it does not see the outgoing packet coming out on
e1000g305000 where it should have been redirected by rule
o_sso-test1:1 (nor does it show up on e1000g0), hence my remark:


> | But again the reply packet seems to be lost in thin air.
> ...


> What you might like to do is start with two rules, "log in all" and
> "log out all" and find out how ipfilter sees the network traffic with
> respect to the virtual network interfaces and the real ones.

I used "ipf -l pass,block,nomatch" to see all packets.

>
> It may be that ipfilter is not seeing the packets associated with
> network interfaces like you might expect.

Both the incoming and outgoing packets match the expected quick ipf
rules: I am happy about what I see in the log of ipfilter.  The
problem in the cases I described is that the reply packets never come
out the interface they have been redirected to (nor any other one).


> ...
> | Context:
> |
> |
> | If it matters, this is occuring in a Solaris 10 zone, whith virtual
> | interfaces one of which uses 801.q tagging (vlan 305, subnet
> ...
> This may have some impact on things...

802.1q does: please read the follow-up I wrote to my own message
(http://marc.info/?l=ipfilter&m=125441699203592&w=2).
Note: the packets sent by the cited "telnet 10.13.4.180 443" go
through a CISCO ACE that rewrite their destination address and send
them to 10.13.5.181.

In my findings I came to the conclusion that, in that context,
ipfilter redirection does not work well when 802.1q tagged interfaces are
involved. More precisely, it works when redirecting from a tagged
interface to a non tagged interface (followup case) but not when
redirecting from a non tagged interface to a tagged one (original post
case; infortunately this is what I would need ).

- Can you reproduce the problem? (on Solaris 10u7?)
- Is this a known issue of ipfilter?

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]