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: u...@domain
Division Informatique                 User=Dominique.Petitpierre
University of Geneva                  Domain=unige.ch


Reply via email to