Hi,

Thanks for the brief explanation about vpn going through NAT and vpn based
on pptp, so the solution right now is to wait for the pptp-proxy to be
created. How about linux ipcop, how come it works, we didn't configure
anything regarding vpn, we just followed the steps on setting up the
firewall and thats it. Does linux already have a solution for this (vpn
going thru NAT)? 


Kind regards,

Appie



Siju George wrote:
> 
> On 3/26/07, Appie <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Been using OpenBSD 4.0 w/ PF for a quite a while now, everything is
>> running
>> perfectly smooth, our setup is to block all incoming packets while allow
>> all
>> for outbound packets as long as connections are initiated from within our
>> local lan. The only problem we encountered was that we can't connect
>> simultaneous vpn connections to via windows XP vpn connectivity to our
>> branch server. We can connect one at a time. Is there something I need to
>> configure? We Tested it with another firewall setup (ipcop firewall) and
>> it
>> works. Hoping for your help. Thanks much.
>> --
> 
> Most probably you are sufferring from the PPTP problem with OpenBSD and
> PF.
> 
> This is an excerpt from his website
> 
> =======================================================================
> NAT relies on the uniqueness of the source and destination IP
> addresses and ports of each TCP and UDP packet.
> 
> Whereas PPTP is a protocol over IP and it uses neither TCP nor UDP for
> encapsulation. Instead it uses GRE which is a protocol over IP.
> 
> PPTP has a control phase in which it negotiates parameters over a
> control connection. This happens over destination TCP port 1723. You
> know that the destination TCP port of HTTP is 80. This is exactly like
> that.
> 
> However, once the PPTP control negotiation is over, the VPN tunnel
> packets go over GRE which has no concept of port numbers. So the only
> way a router identifies different GRE tunnels are by looking at the
> destination IP address. Since NAT hides multiple destination IP
> addresses behind a single global IP address, the NAT device has very
> good reason to get confused as to which private IP address a
> particular GRE packet corresponds to.
> 
> PPTP fortunately has a concept of callid for multiplexing simultaneous
> PPTP sessions. Even here we have a difficulty. Usually with TCP or IP,
> the source and destination port numbers are sent in the header of each
> packet.
> 
> Whereas in the case of PPTP, only the destination callid is present in
> each packet. So incoming packets have the callid of the PPTP client
> and outgoing PPTP packets have the callid of the PPTP server.
> 
> How does the NAT machine determine the internal IP address the callid
> corresponds to?
> 
> To make things worse, as is to be expected from Micro$oft products,
> the incoming callid is always 0 for PPTP clients. So this makes it
> technically infeasibly to multiplex.
> =========================================================================
> 
> The last time i talked with him he said he is writing a PPTP proxy for
> OpenBSD and PF just like the FTP-Proxy. So it should be available soon
> :-)
> 
> Kind Regards
> 
> Siju
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/VPN-tf3465334.html#a9684762
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Reply via email to