[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