On Tue, Dec 22, 1998 at 06:25:09AM +0000, Stuart Lynne wrote: > In article <19981222005418.28373.qmail@mail.ocs.com.au>, > Keith Owens <kaos@ocs.com.au> wrote: > >On 21 Dec 1998 23:14:29 GMT, > >sl@whiskey.fireplug.net (Stuart Lynne) wrote: > >>In article <19981221161532.25174.qmail@mail.ocs.com.au>, > >>Keith Owens <kaos@ocs.com.au> wrote: > >>>If both IPv6 and masq are active, incoming v6-in-v4 packets are > >>>discarded by masq. Quick and dirty workaround against 2.1.131, by no > >>>means the full fix for masq and tunnels. [snip] > >> > >>Similiar problems exist with tunnels and masquerading. In some cases incoming > >>tunnel packets can end up being checked by ip_fw_demasquerade() which will > >>fail causing the packet to be dropped. [snip] > > > >I did say it was a quick and dirty work around :). The whole question > >of masq, firewalls and tunnels gives me the shivers. Do you masq > >before tunnelling, after tunnelling or both? How many levels down into > >the packet do you go for a firewall? How do you hook into v6 in v4 in > >GRE? Why does the word "STREAMS" keep floating through my mind? > > Well the ordering seems to by contolled by ipchains. I know the > problem I found can be circumvented with different rulesets. But > it was certainly fun tracking down why tunnels worked sometimes > and not for other configurations. > > In it's current implementation ip_masq doesn't attempt to implement > masquerading for certain protocols (such is IPIP or GRE) so it > probably shouldn't be getting in the way. It should only attempt > to de-masquerade packets for protocols that it knows about.
Alan Cox's patch-2.1.131-ac10+ fixes this ip_masq bug (the input
path ALWAYS touch masquerader, now it correctly returns "GO ON" if
unknown proto).
== free collective power ==---.
Linux <------------'
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu