IPSec goes down with high throughput…
-
Well, turning off DPD seems to make the issue less acute, but stilll…
Last night (with less traffic elsewhere to naturally slow down my link), things went down quickly regardless of DPD being turned on or off. So I can remove that from the list of potential culprits.
Also, things are a bit more stable from my WiFi connected laptop, because it seems the WiFi network acts somewhat like a throttle, meaning the bandwidth is less likely to be pushed up where things go down. But of course that's no solution.
Have yet to get bandwidth limiters working. :(
-
Is there some reason I'm missing why you can't use site-to-site openvpn for this and MUST use ipsec?
Inside openvpn on the client side there is a handy little box:
Limit outgoing bandwidth (insert bandwidth limit)
Maximum outgoing bandwidth for this tunnel. Leave empty for no limit. The input value has to be something between 100 bytes/sec and 100 Mbytes/sec (entered as bytes per second).(I eagerly await an irritated reply)
P.S. I'm still not convinced that your ISP isn't trashing your connection when you start pulling more upload-bandwidth than they feel like giving you.
I've seen ISPs throttle and reset connections over and over, although they never admit to the practice. I think its part of their business model. If the connection does drop or is reset by the ISP or the modem flaking for a second or whatever, raccoon will not, in my experience, successfully renegotiate that client connection and begin passing data again. It will reconnect. Show connected on both sides, but will not pass any traffic until you reset raccoon (as you mentioned earlier). It will also fill your IPsec logs with exactly the same errors every time this happens. The changes recently made to IPsec in pfsense account for WAN IP changes. The raccoon process will auto restart if WAN IP changes, but it doesn't account for a connection being reset or dropping out for a minute or 2. I think that feature should be added though and should reset raccoon exactly same way it would if a WAN IP changed. Currently IPsec is only any good for me over connections that never falter. -
Is there some reason I'm missing why you can't use site-to-site openvpn for this and MUST use ipsec?
Inside openvpn on the client side there is a handy little box:
Limit outgoing bandwidth (insert bandwidth limit)
Maximum outgoing bandwidth for this tunnel. Leave empty for no limit. The input value has to be something between 100 bytes/sec and 100 Mbytes/sec (entered as bytes per second).(I eagerly await an irritated reply)
Sorry to disappoint you on the irritated part ;) While I'm irritated by the facts, I'm not with the people who try to help.
The reason for not using OpenVPN istwofoldthreefold:
a) the ZyWall at the other end can't do it
b) the second pfSense box that is destined to replace that ZyWall unit is sitting here waiting for the release of 2.1, because I don't want to risk some update glitch and then being in a position to have to book a flight to Michigan to bring the unit back under control. And since things worked reliably until recently, there wasn't a big problem with waiting. If I can't find a solution (e.g. get the bandwidth throttling to work), then I may have to reconsider.
c) the web configurator and OpenVPN would likely run on the same port and possibly interfere with each other (don't like non-standard ports if I can avoid it), and also, I rather avoid the encryption overhead, if I can avoid it. So once I have a second pfSense box there, I may try with simple IP tunnels like GRE or the like, provided my ISP won't filter them out.P.S. I'm still not convinced that your ISP isn't trashing your connection when you start pulling more upload-bandwidth than they feel like giving you.
I've seen ISPs throttle and reset connections over and over, although they never admit to the practice. I think its part of their business model. If the connection does drop or is reset by the ISP or the modem flaking for a second or whatever, raccoon will not, in my experience, successfully renegotiate that client connection and begin passing data again. It will reconnect. Show connected on both sides, but will not pass any traffic until you reset raccoon (as you mentioned earlier). It will also fill your IPsec logs with exactly the same errors every time this happens. The changes recently made to IPsec in pfsense account for WAN IP changes. The raccoon process will auto restart if WAN IP changes, but it doesn't account for a connection being reset or dropping out for a minute or 2. I think that feature should be added though and should reset raccoon exactly same way it would if a WAN IP changed. Currently IPsec is only any good for me over connections that never falter.Well, I wouldn't put it past Verizon to do something like that. But since I only use bandwidth in bursts e.g. downloading a software update or something like that, it would be pretty low if Verizon would on one hand charge me big bucks for the higher FiOS bandwidth, and then throttle me on smallish downloads here and there. I mean we're talking things like a few tens of megabytes worth of downloads, with major idle periods interrupted only by a trickle of incoming e-mails and some random script-kiddy attack attempts on my address block (which don't take up a lot of bandwidth). So it's not like I'm anywhere near pushing the official specs of the connection. So if Verizon were intentionally do this under these circumstances, it would be darn low on their side.
-
Yeah - I read the specs on your little IPsec appliance. It looks pretty nice. Too bad it doesn't support something other than IPsec.
As far as the encryption overhead goes, IPsec has that also.
As far as waiting on the 2.1 release, I wouldn't. 2.03 is stable and works very well with openvpn NOW.
2.1 is an RC with no official release date. Could be today or next year. I don't know.
Its also not like 2.03 is going to break and quit working just because 2.1 is released.
You might find yourself with a reliable bullet proof connection on 2.03 and not want to tempt fate with an update.
If you are serious about not caring about encryption, I think point-to-point L2TP would be fastest although openvpn has been so solid for me I couldn't imagine wanting to not use it. As far as conflicts with Openvpn and Web Configuator, you can run one on port 80 and the other on port 443. They won't interfer and it shouldn't hurt your security if you put the web configuator on http because if you are sane at all you will only access it via the vpn or ssh anyway. -
Is there anyway you can try pfSense 1.2.3 for this testing - just to see if it exhibits same IPSEC issue?
-
Is there anyway you can try pfSense 1.2.3 for this testing - just to see if it exhibits same IPSEC issue?
Pretty difficult. If I could import a 2.1 settings file into a 1.2.3 setup, I could flash a 1.2.3 image on a CF card and have the system boot from that instead of from the SATA SSD. But trying to recreate that setup, particularly since I never worked with the 1.x versions of pfSense, would be rather error prone, and thus may not say much.
Is there a specific reason why you're suggesting that test?
-
Yeah - I read the specs on your little IPsec appliance. It looks pretty nice. Too bad it doesn't support something other than IPsec.
As far as the encryption overhead goes, IPsec has that also.Sure, I'm aware of the IPSec encryption overhead with pfSense. The ZyWall would allow a NULL encryption, which would turn the whole thing into a simple tunnel, but pfSense doesn't allow that.
Of course, once I have a pfSense box on either side, I can just use some other tunnel that can be used without encryption, but ironically, then the encryption overhead won't matter that much anymore (except for lowering latency a bit) because the CPUs on both sides will be sufficiently powerful
-
I'm sure things will change with IPSEC stability and resilience for the better in pfsense soon. There are just too many smart guys I see here paying attention to it, even though most of them don't seem to like, want or need it.
Of course, by then you will not want to use it. You will be sold on OpenVPN :P -
-
I got that question wrong also… Its kettle right? ::)
