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: > > 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#a9686323 Sent from the openbsd user - misc mailing list archive at Nabble.com.
