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

List:       ipfilter
Subject:    Re: truncated-ip (wrong IP header byte swapping?)
From:       Jim Klimov <jimklimov () cos ! ru>
Date:       2009-04-30 11:10:20
Message-ID: 20244_1241090191_49F9888F_20244_884_1_49F9871C.6070800 () cos ! ru
[Download RAW message or body]

Darren Reed wrote:
 > Describe your configuration?
detailed below

 >
 > Are you using NAT?
In some attempts, yes. When I tried with an empty
ipnat.conf and an absent one (restarting IPF with
unloading the module to be certain), the problem
was still there. Just loading the ipf module and
then running "ipf -Fa" already triggers it.

I thought and maybe claimed that loading the ipf
module already triggers the problem; that happens
to be not so; but unloading the module does clear
the problem.

 >
 > Are you tracerouting "through" it?
 > Or from it?
"Through". Traces "from" it seem to work (get replies
from other routers and hosts).


 > I've seen you say it is a 1-NIC problem?

No, not quite so. During these tests I touched 4 setups
explained below. As I lined them up I see that the two
setups which show the error use VLANs, while the working
ones use plain NICs. Perhaps this means something :)

In the 1-NIC case I couldn't *reproduce* the problem,
i.e. traces through that system passed okay, but that
could be for a large number of reasons including the
1-NIC "condition", as well as stock IPF version, no
VLANs on that system, etc.

# Servers which have broken IP headers

1) Our new gateway host which I set out to be made of
    everything versioned fresh to try out new features.

This host is a Sun X2100 with one "bge" and one "nge"
NIC, currently runs Solaris 10u6 x64 patched with the
April 1, 2009 Recommended Cluster patch set.

These two NICs are subdivided into VLAN interfaces and
a few aliased interfaces; some are links to internal
nets, some face the various providers we have around
the university (two or three different backbones).

Since our recent tests with OpenVPN, tun/tap interfaces
also came into play. Seems that with IPF 4.1.28 I have
NAT working over a tap0 interface. In this aspect, our
gw is a client to a remote OpenVPN server; their LAN
doesn't know of our internal networks and can't route
back to us (beside the fact that it would be insecure) -
so for two-way routing to work (and for security) we
NAT our connections to them. This now works with IPF4.

2) A server working in a remote project, with Solaris
10u4 x64 (maybe patched up) and 4 e1000g NICs. All of
its active interfaces except loopback are tagged VLANs.

# Servers which work

3) Our old gateway with Solaris 8 i386, IPFilter 4.1.28
and several elxl (3com) NICs with numerous aliased
addresses (no VLANs as elxl can't make them). It just
works, but in another location. And it's too old for
processing many NAT sessions. And has too few NICs :)

4) Another Sun X2100 with Solaris 10u6 x64 (unpatched)
and its stock IPFilter 4.1.9. It has one plumbed NIC
with a single address. It has an alias IP used for a
Solaris local zone.

This system was only used to see whether its IPF also
fails. This test was limited in a number of ways but,
at least, the loaded+flushed ipf module did not mangle
the packet headers.

For that test I did these steps:
   ndd-enabled ip_forwarding,
   set a few IPF rules (pass in/out quick all),
   modload'ed ipf,
   set this host (192.168.186.25) as a next-hop for
     another machine (192.168.186.71) in the same
     subnet:

# route add 192.168.117.5 192.168.186.25
add host 192.168.117.5: gateway 192.168.186.25

   traced from this other machine - and got good replies
     like these below:

# traceroute -nI 192.168.117.5
traceroute: Warning: Multiple interfaces found;
   using 192.168.186.71 @ hme0:1
traceroute to 192.168.117.5 (192.168.117.5), 30
   hops max, 40 byte packets
  1  192.168.186.25  1.163 ms  0.503 ms  0.390 ms
  2  192.168.186.1  0.736 ms  0.399 ms  0.396 ms
  3  192.168.117.5  0.830 ms  0.825 ms  0.798 ms

//Jim




-- 


+============================================================+
|                                                            |
| Климов Евгений,                                 Jim Klimov |
| технический директор                                   CTO |
| ЗАО "ЦОС и ВТ"                                  JSC COS&HT |
|                                                            |
| +7-903-7705859 (cellular)          mailto:jimklimov@cos.ru |
|                          CC:admin@cos.ru,jimklimov@mail.ru |
+============================================================+
| ()  ascii ribbon campaign - against html mail              |
| /\                        - against microsoft attachments  |
+============================================================+


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