Re: ipf redirection feature functional on Solaris 10?
[email protected] Sat, 14 Nov 2009 03:10:58 +0100
| Newsgroups | gmane.comp.security.firewalls.ipfilter |
|---|---|
| Message-ID | <18225_1258164889_4AFE1298_18225_8943_1_20091114031058.t23xnkotsosos4g4@webmail.unige.ch> |
Hello, Thanks for your reply: Quoting Darren Reed <[email protected]>: > ... > | 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