TCP vs. UDP connection through PF - BSD

This is a discussion on TCP vs. UDP connection through PF - BSD ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: TCP vs. UDP connection through PF

  1. TCP vs. UDP connection through PF

    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



  2. Re: TCP vs. UDP connection through PF

    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

  3. Re: TCP vs. UDP connection through PF

    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



  4. Re: TCP vs. UDP connection through PF

    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

+ Reply to Thread