[ale] Poptop
Geoffrey
esoteric at 3times25.net
Tue Mar 14 09:09:07 EST 2006
Michael H. Warfield wrote:
> On Tue, 2006-03-14 at 08:28 -0500, Geoffrey wrote:
>> Christopher Fowler wrote:
>>> On Mon, 2006-03-13 at 19:44 -0500, Tony Carter wrote:
>>>>> will need client software. I know CISCO makes a nice
>>>>> package, but I don't know if it works with Linux.
>>>> Yup, it works like a charm.. The Mac client even works well.
>>>>
>>> But you still have to have a public IP on the VPN server right?
>> I didn't want to jump into this fray as I don't recall all the
>> specifics, but....
>
>> Back when I was with AT&T I had a successful solution for pptp from a
>> nat'ed machine at my home to a nat'ed machine on the AT&T network.
>
>> So, I know it can be done, I just don't recall all the specifics. I do
>> have some old scripts I believe assisted in this process and I'll share
>> the PPTP specifics here. I've not researched this, so I don't know that
>> these are the working scripts, but I saved them for a reason. :)
>
>> # PPTP for vpn
>
>> VPN_SVR=XXX.XXX.XXX.XXX
>
>> $IPCHAINS -A forward -j MASQ -p tcp -s 172.16.10.215/32 \
>> -d $VPN_SVR/32 1723 -i ppp0
>> $IPCHAINS -A output -j ACCEPT -p tcp -s $IPADDR/24 \
>> -d $VPN_SVR/32 1723 -i ppp0
>> $IPCHAINS -A input -j ACCEPT -p tcp -s $VPN_SVR/32 1723 \
>> -d $IPADDR/24 -i ppp0
>> $IPCHAINS -A forward -j MASQ -p 47 -s 172.16.10.215/32 \
>> -d $VPN_SVR/32 -i ppp0
>> $IPCHAINS -A output -j ACCEPT -p 47 -s $IPADDR/24 \
>> -d $VPN_SVR/32 -i ppp0
>> $IPCHAINS -A input -j ACCEPT -p 47 -s $VPN_SVR/32 \
>> -d $IPADDR/24 -i ppp0
>
> Based on your chains above, I would have to guess that $VPN_SVR was the
> global address on which you could contact that PPTP server. It might
> have been relayed, passed through, or SNAT'ed to another server on a
> private address but that address had to be public.
This is correct.
>> I also recall that I had some modules that had to be loaded as well, but
>> don't recall the specifics of them either. (gre??)
>
> Yes, the older (W2K) PPTP used GRE (Generic Routing Encapsulation)
> tunnels for its transport.
>
>> Note the references above to the 172.16.10.* network was my internal
>> nat'ed subnet.
>
> How was the other end "nat'ed"? Did you set that up or did someone
> else? How does the "nat'ed machine" at the other end come into play
> here? Was he a VPN endpoint or were you merely able to reach him, once
> the VPN was up (VPN server on a global unicast address).
The machine on the other end was natted and someone on the other end set
it up. It's been a long while ago, but I do know that I had to work
with someone on that end to get this working.
--
Until later, Geoffrey
More information about the Ale
mailing list