06-27-2017 04:39 AM
I have been running OpenVPN server on ER-X on default UDP/1194 for a while, but can't change it now to port 443.
Here is what I did:
I changed gui port
set service gui https-port 9443
I deleted UDP config on vtun0 interface
delete interfaces openvpn vtun0 openvpn-option '--port 1194'
delete interfaces openvpn vtun0 openvpn-option '--proto UDP'
I changed vtun0 to TCP/443
set interfaces openvpn vtun0 openvpn-option '--port 443'
set interfaces openvpn vtun0 protocol tcp-passive
and finally updated firewall
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL description 'WAN to router'
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 description 'Allow established/related'
set firewall name WAN_LOCAL rule 10 destination
set firewall name WAN_LOCAL rule 10 log disable
set firewall name WAN_LOCAL rule 10 protocol tcp
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state invalid disable
set firewall name WAN_LOCAL rule 10 state new disable
set firewall name WAN_LOCAL rule 10 state related enable
set firewall name WAN_LOCAL rule 30 action drop
set firewall name WAN_LOCAL rule 30 description 'Drop invalid state'
set firewall name WAN_LOCAL rule 30 state invalid enable
set firewall name WAN_LOCAL rule 60 action accept
set firewall name WAN_LOCAL rule 60 description 'OpenVPN Server'
set firewall name WAN_LOCAL rule 60 destination port 443
set firewall name WAN_LOCAL rule 60 log disable
set firewall name WAN_LOCAL rule 60 protocol tcp
set firewall name WAN_LOCAL rule 60 state established disable
set firewall name WAN_LOCAL rule 60 state invalid disable
set firewall name WAN_LOCAL rule 60 state new enable
set firewall name WAN_LOCAL rule 60 state related disable
However, my VPN client constantly get stuck with message "Attempting to establish TCP connection with [AF_INET]x.x.x.x:443 [nonblock]" - replaced ip address with x.x.x.x
Here is the full connection log from the client:
"2017-06-27 21:23:43: State changed to Connecting
2017-06-27 21:23:43: Checking reachability status of connection...
2017-06-27 21:23:43: Testing address: x.x.x.x Reachable
2017-06-27 21:23:43: Connection is reachable. Starting connection attempt.
2017-06-27 21:23:44: OpenVPN 2.4.2 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on May 26 2017
2017-06-27 21:23:44: library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.09
2017-06-27 21:23:44: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2017-06-27 21:23:44: TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:443
2017-06-27 21:23:44: Attempting to establish TCP connection with [AF_INET]x.x.x.x:443 [nonblock]"
When I check firewall stats I don't see any traffic hitting this new rule:
IPv4 Firewall "WAN_LOCAL" [WAN to router]
Active on (eth0,LOCAL)
rule packets bytes action description
---- ------- ----- ------ -----------
10 28 3066 ACCEPT Allow established/related
30 136 11160 DROP Drop invalid state
60 0 0 ACCEPT OpenVPN Server
10000 518 65503 DROP DEFAULT ACTION
However, when I connect my computer to LAN the VPN client successfully establishes the connection.
So, I am a bit lost here. Any idea what I am doing wrong?
06-27-2017 05:08 AM
Don't use TCP for OpenVPN. It will have a significant impact on the performance, especially with rather unreliable network connections with lots of packet loss like wifi. If a vpn packet gets lost, TCP will retransmit it. In the meantime the application might run into a timeout as well and retransmit the packet once more!
Stick to UDP. If an application needs TCP, it will use TCP, encapsulated in an UDP vpn packet. If the vpn packet (UDP) gets lost, the application will resend the packet as above but the vpn itself won't care about lost packets (because the application handles it with its encapsulated TCP connection).
However, this doesn't help with your port problem, sorry. Unfortunately I have no ER in reach so I can't reproduce the problem right now.
06-27-2017 05:29 AM
Nope, I have no DNAT rules. There is a single default NAT masquerade for regular internet traffic
that's all I have
set service nat rule 5010 description 'masquerade for WAN'
set service nat rule 5010 log disable
set service nat rule 5010 outbound-interface eth0
set service nat rule 5010 protocol all
set service nat rule 5010 type masquerade
06-27-2017 05:37 AM
So you are in a guest wifi and want to connect from there to your ER at home (#1)? Or is the ER in the guest network and you want to connect to it from somewhere else (#2)?
If #1 is the case, try UDP 53 for example. That's the DNS port and is usually unblocked as well. Maybe the ER "doesn't like" the https port to be used by OpenVPN?
06-27-2017 05:39 AM
I am in guest WiFI and want to connect to my homelab through OpenVPN on ER.
There are so many examples of people configuring OpenVPN on TCP/443. There is something wrong with my setup I suspect.
06-27-2017 05:47 AM
Well, then try it from a different location. Pick up a sixpack from the supermarket, visit your neighbour, offer him a beer and use his internet connection to test the VPN
This way you can verify that the setup works on your side. If it's working from your neighbours' but not from the mentioned guest wifi I guess the firewall in the guest wifi blocks the traffic - be it by port or by DPI.
06-27-2017 03:58 PM
I reverted it back now to UDP, but I am pretty sure OpenVPN was working on TCP/443
When I had my laptop connected to LAN interface of the router and tried to connect over OpenVPN it worked just fine. Even though OpenVPN client was trying to connect to WAN IP address of my router it somehow established OpenVPN tunnel.
But when I connected my computer to 4G modem and tried to connect to the OpenVPN over internet it failed.
So, to me it looks like something wrong with firewall rules or my OpenVPN client.
06-27-2017 11:35 PM
Well, when you connect to your public IP from LAN the ER will use NAT hairpin / loopback.With NAT loopback the traffic will exit and reenter the WAN interface. As soon as the packets reenter WAN they will be treated as external traffic and pass all nat and firewall rules.
Maybe your 4G provider is blocking traffic as well. You should try again from a non-mobile internet connection - like the neighbour's as suggested earlier.