Apparently flakey behavior with DNAT, SNAT, and masquerading
Ramin Alidousti
ramin@UU.NET
Fri, 22 Jun 2001 12:43:41 -0400
On Fri, Jun 22, 2001 at 10:52:04AM -0500, Greg Scott wrote:
> Here is the relevant text from that HOWTO:
>
> 2.10 Why patch the Linux kernel?
>
> The largest problem in masquerading VPN traffic is that the
> stock Linux IP masquerade has no special awareness of IP
> protocols other than TCP, UDP and ICMP.
>
> All IP traffic may be forwarded and filtered by IP address,
> but masquerading IP protocols other than TCP, UDP and ICMP
> requires modifying the kernel.
>
> The PPTP control channel is plain TCP and requires no special
> setup beyond letting it through the firewall and masquerading it.
>
> Masquerading the IPsec and PPTP data channels requires a
> modification that adds support for the ESP and GRE protocols
> to the masquerading code, and masquerading the ISAKMP key
> exchange protocol requires a modification that prevents masquerade
> from altering the UDP source port number and adds tracking of the
> ISAKMP cookie values instead of the port number.
>
> Could this still be true?????
I'm not sure, Greg. From the output of your tcpdump the gre nat on
your linux gateway next to the vpn server was working properly, wasn't
it? And besides, you say that the client without a cisco in between
works fine, which also uses gre nat, right?
So, my short answer is "no". But I might be wrong.
>From your setup and explanations I understand that the cisco is
doing something which breaks the communication. For a while I
was on the track of MTU stuff, because of the known misbehavior
of the 2000/ME boxes when the MTU has a mismatch but I think that
you proved that that was not the case.
What bothers me is the ICMP "protocol unreachable" messages coming
from the client. It's as if it doesn't understand GRE anymore while
I could see some GRE packets going back and forth for a while.
What was the result when someone dialed in and set up the vpn, without
any intermediate natting? Did it work?
Ramin
>
> - Greg