PPTP and PF NAT

[David Young]

I have a private network where two or more VPN clients need to
simultaneously connect with the same PPTP VPN concentrator on the web.
Between the clients and the wider Internet is my PF NAT firewall. One
VPN client can connect, but a second client cannot. The reason is that
PF NAT does not grok PPTP or GRE in general, so it cannot use the Call
ID field to distinguish the packets sent by the concentrator to one
client from packets sent to another client.

Is this problem familiar to anyone? Is there any workaround, short of
patching my kernel to track PPTP sessions? On the web, I've found out
that there are two patchsets for tracking PPTP sessions in PF, so I will
be trying those if no other solution shows up.

Dave

[der Mouse]

Post by David Young
I have a private network where two or more VPN clients need to
simultaneously connect with the same PPTP VPN concentrator on the web.

PPTP uses the Web? I thought it was layered directly atop UDP, or
maybe even IP, like most VPNish things.

Post by David Young
Between the clients and the wider Internet is my PF NAT firewall.

You've probably just found yet another casualty of the way NAT breaks
the assumptions underlying IP networking. Break the assumptions and
you break things built on those assumptions; it's a tribute to the
robustness of the protocols that as many of them work as do.

About all I have to suggest is "don't do that" - don't try to use
behind-NAT connectivity as if it were full-on IP connectivity. (I make
no pretense to thinking you will consider this helpful; given your
phrasing, I feel moderately sure you would prefer to paper over the
brokenness rather than fix it in this case. And as to papering it
over, I don't know enough about PPTP, but if it really is layered atop
the Web, it might be worth looking into why it isn't being handled by
the generic TCP tracking in your NAT.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jordan Gordeev]

Post by David Young
Is this problem familiar to anyone? Is there any workaround, short of
patching my kernel to track PPTP sessions? On the web, I've found out
that there are two patchsets for tracking PPTP sessions in PF, so I will
be trying those if no other solution shows up.

If possible, you should consider switching to L2TP.
It's considered the successor to PPTP and runs over UDP, which makes it
perfectly NAT-able.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Jordan Gordeev

Post by David Young
Is this problem familiar to anyone? Is there any workaround, short of
patching my kernel to track PPTP sessions? On the web, I've found out
that there are two patchsets for tracking PPTP sessions in PF, so I will
be trying those if no other solution shows up.

If possible, you should consider switching to L2TP.

Sadly, it is not possible. :-( The VPN clients have to work with an
existing VPN concentrator that is configured to support PPTP, only. The
concentrator is not under my control.

Dave

[David Young]

Post by David Young
I have a private network where two or more VPN clients need to
simultaneously connect with the same PPTP VPN concentrator on the web.
Between the clients and the wider Internet is my PF NAT firewall. One
VPN client can connect, but a second client cannot. The reason is that
PF NAT does not grok PPTP or GRE in general, so it cannot use the Call
ID field to distinguish the packets sent by the concentrator to one
client from packets sent to another client.
Is this problem familiar to anyone? Is there any workaround, short of
patching my kernel to track PPTP sessions? On the web, I've found out
that there are two patchsets for tracking PPTP sessions in PF, so I will
be trying those if no other solution shows up.

Just in case anybody is interested to see how I solved the problem, I
took advantage of the fact that we had 14 external IP numbers and only
about 8 workstations on the LAN that need to connect to the VPN. I
wrote two NAT rules for each workstation, one affecting the connections
to the VPN concentrator at TCP port 1723, and one affecting the GRE
packets:

nat on ${wanif} inet proto gre from ${wkstn-a} to any -> ${external-ip-a}
nat on ${wanif} inet from ${wkstn-a} to any port = pptp -> ${external-ip-a}
nat on ${wanif} inet proto gre from ${wkstn-b} to any -> ${external-ip-b}
nat on ${wanif} inet from ${wkstn-b} to any port = pptp -> ${external-ip-b}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de