[Openswan dev] Problems with openswan and bridging

Michael Richardson mcr at xelerance.com
Mon Jun 4 16:37:34 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Rene" == Rene Mayrhofer <rene.mayrhofer at gibraltar.at> writes:
    Rene> master:~# cat /proc/net/ip_conntrack | grep icmp icmp 1 27
    Rene> src=192.168.13.110 dst=192.168.10.130 type=8 code=0 id=512
    Rene> [UNREPLIED] src=192.168.10.130 dst=192.168.13.110 type=0
    Rene> code=0 id=512 use=1 mark=51

    Rene> And this seems to be the main problem. Do you have any idea
    Rene> why connection tracking may not recognize the ICMP replies,
    Rene> although source and destination addresses match (there are no

  Connection tracking is per-interface.
  What I'm unclear about is if the packet that created the connection
went out through the same interface that the reply came back on?
  I think it logically arrived on the right interface, but virtually
arrived on the wrong one.

    Rene> NAT rules on ipsec0, br_int, or int)? It is also quite funny
    Rene> that, as you can see in the syslog output above, that the
    Rene> packet is marked is coming from br_ext instead of from
    Rene> ipsec0. On br_ext, it is only visible as ESP (which is
    Rene> correct).

  That is strange, I agree, and that would be the 
  I actually removed the trip through netfilter for outgoing plaintext
packets (%pass eroutes) from the 2.5 KLIPS, because of some issues.
 
  KLIPS should be making the packet arrive on the ipsec0 interface.
Can you enable rcv + verbose debugging in KLIPS?
  I haven't run much code on a 2.4 kernel base lately either.

    Rene> I'd happy about any advice. The changelog between 2.4.6
    Rene> (that's the KLIPS version currently in use) and 2.4.8 does not
    Rene> hint that this issue would be solved, and recompiling that
    Rene> particular kernel would be a major hassle, so I'd prefer to do
    Rene> it only sparingly.

  Understood.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRmR4B4CLcPvd0N1lAQJeyQf/Q5SsMbSqhmhwh3s3AnX28t70hHj1hok3
s/CWtoO6S79I56H4xcMh6nXE3wrbL+ZB4roUEzq4fjCuM4nmUrs4LbHQwkU8TPzQ
HbiOk1hVnFfrJ3yeGJ62VXxocbNIymCXhMWkeif+z58ZqZofWdTyXrmBAXOarcbp
SD78OZY59duuEyOfuWeoaw+Kf3TVGpCyIrKbSXwhDvpUTh1qcHGmN2W1LoDj30wB
g237mEj94dAX1HNhPx+/3zxQAr7lWznHDoyQwQiJpQDE91P8X/TDzbfOqi2AkKfd
j/XR5C4ZeuPSkedt3Sf3ClyxCBr2TBio5k6RKTpLFCqZ3Y4cTPWLog==
=yyHH
-----END PGP SIGNATURE-----


More information about the Dev mailing list