Yes, my bad. I didn't include any other information because I didn't think it could be version specific. We are using OpenBSD 3.8, and OpenVPN 2.0.6 (from packages).
You are right about IPSec not routing. What I meant is how the configured flows are being chosen/matched so that the OS routes the packets through the enc interface or the dmz interface. We are not using carp on that machine. About the ARP issue, we are not connecting between locally attached hosts, so I'm not sure of what you mean, or how it would affect us. When you say toss, you mean discard? I _can_ see the udp reply packet generated by OpenVPN going through the enc0 using tcpdump when connecting from the Internet. There's also the issue of why flushing and reloading the ipsec tunnels/flows solves the problem temporarily. One thing I forgot to mention that may be part of this problem: when we connect to this machine from the office on the other end, the packets don't go through an ipsec tunnel (ie, no flow is used), but when the box running OpenVPN replies, they _do_ get back trough a flow. The first part is also true for someone connecting from the Internet, but the replying packets should get routed trough the dmz interface going to the Internet, not the enc interface. This does work for some time, until, for some reason, they begin to appear in the enc interface. Let me know if this clarifies my first message and if you need more info. Thanks, Martmn. David Bryan wrote: > You may want to include some more information, like what version of > OpenBSD your running, and one version of OpenVPN your running. > One thing you must remember is that IPSec does not route, packets must > match an IPSec profile and are then that packet is wraped up in an > IPSec header and sent across to the remote end. > > If you can get to it with TCP, but not UDP you may have either an ARP > issue (EG: UDP tosses the packet, and does not try again, and > generally it does not get status messages) or a CARP/PF rule set issue. > > More info is needed before questions can be answered. > > Martmn Coco wrote: > >> Hello misc! >> >> We are experiencing what seems to be a routing problem when using ipsec >> flows and udp traffic. >> >> We are using OpenVPN for the employees to connect from the outside world >> to our network. It is configured to use UDP. At the same time, this box >> has an ipsec tunnel configured to talk between different offices in >> different countries. >> >> The problem seems to be that, at some point in time, all the udp packets >> coming from anywhere end up being routed through the enc0 interface, >> when some of them (the ones coming through the Internet and not from our >> other office) should be routed normally, without using any ipsec flow. >> This of course causes all OpenVPN connection attempts coming from the >> Internet to fail, as they will never receive an aswer from the server. >> >> This is not the first time we've encountered this behaviour. I've also >> seen this happening when using named together with ipsec tunnels. The >> very same thing would happen (ie, packets that should go to the Internet >> being routed via enc0). >> >> We have just realised that in both cases, OpenVPN and named, UDP might >> be in use. When the OpenVPN server begins to "misbehave", I can still >> connect via ssh from the Internet (thus discarding TCP issues). >> >> To solve this we have to flush the ipsec tunnels. This seems to solve >> the issue. >> >> The pf rules seem to be alright, keeping state for udp connections. The >> only thing that we may be doing wrong is the ipsec flow configuration, >> but why would it work for some time, to show the detailed behaviour only >> after a couple of hours? >> >> I'll appreciate your input, >> Martmn.
