Use both TCP and UDP at the same time with OpenVPN Server



  • Hi,

    I want the OpenVPN remote users to use UDP 1194 when available and when on restricted networks, fall back to TCP 443. On client side I added following tags to the config (IPs sanitized):

    <connection>remote 10.1.1.1 1194 udp</connection>
    <connection>remote 10.1.1.1 443 tcp</connection>

    On Pfsense OpenVPN Server, I can see the option to use either UDP or TCP; no option to use both simultaneously.

    Can someone suggest how I could achieve this requirement at server side? and make that listen for both UDP and TCP Clients.

    Thanks!


  • Netgate

    Run two servers.

    OpenVPN 2.4.3 itself cannot listen on both TCP and UDP at the same time.


  • Rebel Alliance Global Moderator

    Yeah just fire up another instance.. I run both tcp 443 and udp 1194 on mine.



  • Hi,
    I have setup two identical Pfsense with same configurations and openvpn certificates and key. One Pfsense is with TCP port 1194 and one with UDP port 1194.
    How I can allow communication between openvpn clients of both Pfsense with each other?


  • Rebel Alliance Global Moderator

    huh? You setup 2 different pfsense.. Another instance of openvpn - not pfsense ;)

    0_1527418353809_2openvpnservers.png

    You can run multiple instances of pfsense on the same box ...



  • Hi Johnpoz,

    Yes, I have setup instance for both TCP and UDP as shown:
    0_1527496355052_vpnservers.PNG

    Also, have added interface OPT2 for new instance:

    0_1527496579970_ddd.PNG

    0_1527496438387_routing.PNG

    Following is connected status of UDP based openvpn client:
    0_1527496450847_udp-status.PNG

    Issue:
    TCP based clients are connecting fine and are able to communicate with other TCP based clients.
    But, UDP clients get connected but there is no data exchange, although there is no firewall blockage.

    My target is to get communication between my TCP clients with UDP clients, Please suggest what I further need to look?


  • Rebel Alliance Global Moderator

    @sohailab

    You do not need to create interfaces for road warrior vpn.

    And tcp 1194.. When is that ever going to be open? If udp 1194 is closed... Bad choice of tcp port if your goal is to make sure users can get to your vpn server.

    If your going to want client to go down the tunnel to get to other vpn client your going to have to tell them to come down the tunnel to get to that other tunnel network. Your 10.0.8 and 10.0.9 networks



  • @johnpoz
    Hi,
    I understand your point.

    But in my scenario, I want communication between openvpn-client connected with OPENVPN-Server (TCP) instance WITH openvpn-client connected with OPENVPN-Server (UDP) instance.

    Do I need to do natting or add some routes for this purpose? Hope you understand my requirement now.



  • Reason of my above requirement is; if only a specific client face connectivity with server using UDP, that could get connected to server using TCP. I don't want my all clients to lose communication from UDP and switch to TCP. For this purpose I need to have communication between a TCP client and UDP client.


  • Rebel Alliance Global Moderator

    @sohailab

    Not sure why clients need to talk to each other to be honest.. I don't really see a common use case for that. If you don't mind to kill off my curiosity could you explain why clients need to talk to each other. Maybe its a non starter in the bigger picture.

    No you do not need to nat, you just need to add your other tunnel network to the local networks in your vpn setup.

    And I understand the point of the tcp when udp doesn't work - I use it myself that way. But 1194 tcp is a horrible choice if you ask me. How about 443 tcp - that is pretty much a given to be open anywhere there is internet access.


  • Moderator

    Don't understand the use case of tcp/1194 or clients talking with clients either (and am curious, too), but the problem of tcp clients unable to talk to udp clients seems firewall related.

    a) make sure you have a firewall rule in place to allow traffic from 10.0.8.0/24 to 10.0.9.0/24 and reverse
    b) make sure - whyever you need it - that the servers itself allow intra-client-traffic (option in openvpn-server configuration)

    If you have created those OPT interfaces, then make sure you create the firewall rules on the right interfaces (or the OpenVPN group interface) and test connectivity again.



  • @jegr @johnpoz thanks.
    I had to allow 10.0.8.0/24 to 10.0.9.0/24 access in openvpn server setting to have access by clients to get communication between vpn clients of different subnets.
    Now things are working fine.

    Conclusion:
    I have two openvpn sevrer instance on Pfsense.
    One instance is using TCP port 1144 (NAT is implemented in our pubic firewall, for public clients port is 443-TCP)
    Other instance is using UDP port 1144 (NAT is implemented in our pubic firewall, for public clients port is 443-UDP)

    On each openvpn server I had to allow subnet of other openvpn server in "IPv4 Local network(s) " field under the tunnel settings.

    Now my TCP based clients of TCP based Openvpn server are able to communicate with UDP based clients of UDP based Openvpn server for my calling and IM setup.


  • Moderator

    @sohailab said in Use both TCP and UDP at the same time with OpenVPN Server:

    @jegr @johnpoz thanks.
    Now things are working fine.

    Happy to hear that!

    I have two openvpn sevrer instance on Pfsense.
    One instance is using TCP port 1144 (NAT is implemented in our pubic firewall, for public clients port is 443-TCP)
    Other instance is using UDP port 1144 (NAT is implemented in our pubic firewall, for public clients port is 443-UDP)

    If you'd take a word of advice - I'd rather configure it to run on 1194/udp and 443/tcp (strictly externally speaking), not run on 443/udp. Why? Because 1194/udp is well known as OpenVPN and if it's open "it just works". Also as the "protocol" or port is known, systems can shape or prioritize the traffic better. On the other hand, if the network you're in is heavily protected, chances are, that 1194/udp is blocked as well as 443/udp as the latter is unknown as running udp and some administrators will find that extremely suspicious, while 1194/udp is known to be OpenVPN. So 443/udp could trigger alarms in firewalls/IDS/etc. that 1194/udp wouldn't and just work. 443/tcp is of course a quite often used solution for public networks that often block many ports or VPNs. :)



  • @jegr Thank you. I will definitely consider your advice :)