SEO

I've been spending the last few days troubleshooting an odd connection
problem to my OpenVPN 2 server, which I eventually narrowed down to a
problem with the local firewalls at the various client sites that I have
tested from. In short without any kind of a firewall the connection goes
through like a champ, but with the firewall in place the connection would
fail on occation. My initial though, probably as yours, was to check over
my firewall rules and verify that I have full in and out bound connection on
the UDP port 1194 (default for OpenVPN) - yet still the problem remains.

So just as a test I changed both my client and server to use TCP (still port
1194) instead of UDP, with no other changes to anything, including the local
firewalls, and lo and behold things work from all sites!

Now I understand the performace issues with TCP vs. UDP for tunneled
packets, so I really would prefer to stick with UDP but for the moment
things are working and that is the most critical thing. However I would
very much like to understand why this is, so I turn to the collective wisdom
of this group.

All of my firewalls are based on OpenBSD, versions 3.4 to 3.6. One is a
filtering bridge and the other two are standard firewalls with a NAT'd range
behind them. The funny thing is that with the bridged location, if I
temporarily disable the firewall rules, the connection (UDP) goes through,
but if I do the same at the firewalled locations it still fails (other
things do process, so the un-filtered NAT process is not interrupted).

I used the following basic rules at all locations:

pass in quick on $ExtIF inet proto udp from any to any port 1194
pass out quick on $ExtIF inet proto udp from any to any port 1194
pass in quick on $IntIF inet proto udp from any to any port 1194
pass out quick on $IntIF inet proto udp from any to any port 1194

This should allow full in/out-bound access to UDP 1194, yet still it does
not work. Yet as I mentioned above if I change the client and server to
both use TCP and change the rules above to TCP then all works perfectly!

Anyone have any idea about this, or the UDP vs. TCP issue?

Thanks,
Peter

Peter Bako wrote:
> Anyone have any idea about this, or the UDP vs. TCP issue?

You are aware of the one fundamental difference between UDP and TCP?
UDP is stateless, that is to say there are no "connections" (as in TCP),
just udp packets flowing through the network.
This means that any application who implements a connection-based
service on top of udp will have to do that part by itself.

This _might_ impact your application going through firewalls.
HTH
--
Torfinn Ingolfsen,
Norway

Peter Bako wrote:

> I used the following basic rules at all locations:
>
> pass in quick on $ExtIF inet proto udp from any to any port 1194
> pass out quick on $ExtIF inet proto udp from any to any port 1194
> pass in quick on $IntIF inet proto udp from any to any port 1194
> pass out quick on $IntIF inet proto udp from any to any port 1194
>
> This should allow full in/out-bound access to UDP 1194, yet still it
> does not work. Yet as I mentioned above if I change the client and
> server to both use TCP and change the rules above to TCP then all
> works perfectly!

Are you sure it's always the _destination_ port which is 1194? Replies to
these packets would pass your firewall with a source-port of 1194 (i guess).

If you want to create a tunnel with udp-port 1194 on both sides, you should
use a nat-rule which tells pf to use port 1194 as source-port after
translation.

HTH
Konfu

On Tue, 31 May 2005 16:19:48 -0700, Peter Bako wrote:

> I've been spending the last few days troubleshooting an odd connection
> problem to my OpenVPN 2 server, which I eventually narrowed down to a
> problem with the local firewalls at the various client sites that I have
> tested from. In short without any kind of a firewall the connection goes
> through like a champ, but with the firewall in place the connection would
> fail on occation. My initial though, probably as yours, was to check over
> my firewall rules and verify that I have full in and out bound connection on
> the UDP port 1194 (default for OpenVPN) - yet still the problem remains.
>
> So just as a test I changed both my client and server to use TCP (still port
> 1194) instead of UDP, with no other changes to anything, including the local
> firewalls, and lo and behold things work from all sites!

Your PF-rules below neet to take server-replies into account (from
1194/udp to any/udp). Depending on the application-protocol that may have
to be done both ways.

>
> Now I understand the performace issues with TCP vs. UDP for tunneled
> packets, so I really would prefer to stick with UDP but for the moment
> things are working and that is the most critical thing. However I would
> very much like to understand why this is, so I turn to the collective wisdom
> of this group.
>
> All of my firewalls are based on OpenBSD, versions 3.4 to 3.6. One is a
> filtering bridge and the other two are standard firewalls with a NAT'd range
> behind them. The funny thing is that with the bridged location, if I
> temporarily disable the firewall rules, the connection (UDP) goes through,
> but if I do the same at the firewalled locations it still fails (other
> things do process, so the un-filtered NAT process is not interrupted).
>
> I used the following basic rules at all locations:
>
> pass in quick on $ExtIF inet proto udp from any to any port 1194
+pass in quick on $ExtIF inet proto udp from any port 1194 to any
> pass out quick on $ExtIF inet proto udp from any to any port 1194
+pass out quick on $ExtIF inet proto udp from any port 1194 to any
> pass in quick on $IntIF inet proto udp from any to any port 1194
+pass in quick on $IntIF inet proto udp from any port 1194 to any
> pass out quick on $IntIF inet proto udp from any to any port 1194
+pass out quick on $IntIF inet proto udp from any port 11984 to any

>
> This should allow full in/out-bound access to UDP 1194, yet still it does
> not work. Yet as I mentioned above if I change the client and server to
> both use TCP and change the rules above to TCP then all works perfectly!

As show above you need to pass the replies as well as requests to 1194/udp.

//Per