login
Search
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. -- View this message in context: http://www.nabble.com/VPN-tf3465334.html#a9668331 Sent from the openbsd user - misc mailing list archive at Nabble.com.
You need to provide more info. Are you using NAT? Are you running IPSEC, PPTP, L2TP, or SSL based VPN?
Is the VPN using IPsec or SSL? -Lars Lars NoodC)n (larsnooden@openoffice.org) Ensure access to your data now and in the future http://opendocumentfellowship.org/about_us/contribute
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 Kind Regards Siju
Frickin works for me on OpenBSD 4.0... http://frickin.sourceforge.net/ Shane J Pearson shanejp netspace net au
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 -- 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.
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 -- 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.
It may not be the wisest thing to be trying PPTP. In addition to the technical problems you are encountering, there seem to be some grave issues with the protocol itself, http://www.schneier.com/pptp-faq.html which are apparently not resolved entirely even in later versions. IPsec and SSL are both standards and, as such, supported even by legacy platforms. It might be useful to phase out PPTP in favor of IPsec. -Lars Lars NoodC)n (larsnooden@openoffice.org) Ensure access to your data now and in the future http://opendocumentfellowship.org/about_us/contribute
PPTP sucks, but if you have some models of Palm device it's all you get to use - they just don't do anything more secure. Sure, it's all software but i have yet to see an IPSec or SSL-based VPN client for my Palm. It's useless wireless won't even do WPA (ok, so I got it IPSec can be confusing to configure the first time round - it took me a little while to come to terms with it. It has the advantage the newer version of Winblows support it out of the box, so your average L-user will have no trouble getting on your VPN. (s/no trobule/minimal trouble/). OpenVPN is ssl-based and seems to work quite well. It's also able to be easily tunneled over HTTP proxies if you need to access the VPN from behind a restrictive firewall. I've used OpenVPN on Linux servers, clients and Windows boxes. Never had a hiccup with it. I don't know how well it works in OpenBSD though. If you're stuck with PPTP just be sure to know its limits. Read the web page posted before and probably keep it on a separate box with different usernames/passwords to your main machines. You might consider allowing access to only certain services via the VPN too, just to limit the damage that can occur due to PPTP's inherrent insecurity. I found that the free servers were really painfully slow too - I don't know whether that's an artificial limitation or not because the server was never very heavily loaded and PPTP wouldn't do more than a couple of megabits a second over a solid wireless connection. Cheers, A
OpenVPN works great on OpenBSD I run it as both a server and client on various machines. You can find it in the ports tree. -- Tim Kuhlman Network Administrator ColoradoVnet.com
