Sori , my mistake , we did put a check mark (enabled) vpn and assign a local
vpn hostname / IP on IPcop's global VPN settings.


Regards,

Rafael



Appie wrote:
quoted text
> 
> 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 <rvfajardo@yahoo.com> 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#a9686323
Sent from the openbsd user - misc mailing list archive at Nabble.com.