[EdgeRouter-X-5] port 1194 forwarden

[FreddyT]

Op mijn EdgeRouter heb ik een viertal port geforward: 80, 1194, 4040 en 8200. Voor 3 van de 4 werkt dat. Echter, voor poort 1194 (OpenVPN) werkt dat niet. Bedoeling is dat er gebruik gemaakt wordt van de FileServer op adres 192.168.1.111 voor OpenVPN en niet van de EdgeRouter zelf. Als ik binnen het netwerk probeer een VPN verbinding te maken dan zie ik met tcpdump het volgende langskomen:

ubnt@EdgeRouter-X-5-Port:~$ sudo tcpdump -i eth0 -n -v host 77.xxx.xx.xx
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:04:59.650244 IP (tos 0x0, ttl 63, id 21647, offset 0, flags [DF], proto UDP (17), length 82)
192.168.2.199.45277 > 77.xxx.xx.xx.1194: UDP, length 54

De logging van OpenVPN laat het volgende zien:
2023-02-16 19:31:39 NOTE: --user option is not implemented on Windows
2023-02-16 19:31:39 NOTE: --group option is not implemented on Windows
2023-02-16 19:31:39 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-02-16 19:31:39 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2023-02-16 19:31:39 OpenVPN 2.5.8 [git:none/0357ceb877687faa] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 2 2022
2023-02-16 19:31:39 Windows version 10.0 (Windows 10 or greater) 64bit
2023-02-16 19:31:39 library versions: OpenSSL 1.1.1s 1 Nov 2022, LZO 2.10
2023-02-16 19:31:39 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2023-02-16 19:31:39 Need hold release from management interface, waiting...
2023-02-16 19:31:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
2023-02-16 19:31:40 MANAGEMENT: CMD 'state on'
2023-02-16 19:31:40 MANAGEMENT: CMD 'log on all'
2023-02-16 19:31:40 MANAGEMENT: CMD 'echo on all'
2023-02-16 19:31:40 MANAGEMENT: CMD 'bytecount 5'
2023-02-16 19:31:40 MANAGEMENT: CMD 'state'
2023-02-16 19:31:40 MANAGEMENT: CMD 'hold off'
2023-02-16 19:31:40 MANAGEMENT: CMD 'hold release'
2023-02-16 19:31:40 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-02-16 19:31:40 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-02-16 19:31:40 MANAGEMENT: >STATE:1676572300,RESOLVE,,,,,,
2023-02-16 19:31:40 TCP/UDP: Preserving recently used remote address: [AF_INET]77.xxx.xx.xx:1194
2023-02-16 19:31:40 Socket Buffers: R=[65536->65536] S=[65536->65536]
2023-02-16 19:31:40 UDP link local: (not bound)
2023-02-16 19:31:40 UDP link remote: [AF_INET]77.xxx.xx.xx.71:1194
2023-02-16 19:31:40 MANAGEMENT: >STATE:1676572300,WAIT,,,,,,

Als ik met de telefoon op 4G een VPN verbinding probeer te maken, zie ik niets langskomen met tcpdump.

Met mijn vorige router heeft dit altijd gewerkt. Wat is er zo speciaal aan het forwarden van poort 1194 dat dit niet lukt en de andere poorten wel? En nog veel interessanter: hoe kan ik zorgen dat dit wel lukt?

De EdgeRouter staat achter een Experia10 box, waarvan ik de benodigde poorten forward naar de EdgeRouter.

Wat (hopelijk relevante) delen van de configuratie:

name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action accept
description OpenVPN
destination {
address 192.168.1.111
port 1194
}
log disable
protocol udp
source {
port 1194
}
}
rule 30 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 10 {
action accept
description OpenVPN
destination {
address 192.168.1.111
port 1194
}
log disable
protocol udp
source {
port 1194
}
}
rule 20 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 30 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable

port-forward {
auto-firewall enable
hairpin-nat enable
lan-interface switch0
rule 1 {
description WebServer
forward-to {
address 192.168.1.111
port 80
}
original-port 80
protocol tcp
}
rule 2 {
description OpenVPN
forward-to {
address 192.168.1.111
port 1194
}
original-port 1194
protocol udp
}
rule 3 {
description CherryMusic
forward-to {
address 192.168.1.111
port 4040
}
original-port 4040
protocol tcp
}
rule 4 {
description miniDLNA
forward-to {
address 192.168.1.111
port 8200
}
original-port 8200
protocol tcp
}
wan-interface eth0
}

[Frogmen]

Je hebt de poort dubbel geforward want je doet aan dubbel natten daar zit je probleem in denk ik. openvpn laat zich niet dubbel natten. De server krijgt namelijk het IP adres van de Experiabox mee als extern IP adres en daar krijgt hij geen connectie mee.
Maar waarom niet de VPN van X-router gebruiken en eventueel alleen je server als intern IP adres toestaan.

[Ben(V)]

Onzin, een OpenVPN server werkt prima achter dubbel Nat.

Als de forward goed staan dan werkt dat prima.
De connectie wordt door de OpenVPN client geïnitieerd en eerst door de Experiabox geforward naar de Edgerouter en die forward het weer naar de het systeem waar de OpenVPN server op draait.

De OpenVPN server weet helemaal niets van z'n externe IP adres, dat is iets wat de VPN client moet weten en dat moet uiteraard het Wan IP-adres van de Experiabox zijn.

Kortom het probleem moet echt in de Edgerouter zitten.
En waarschijnlijk gebruikt hij een ander server omdat die Edgerouter niet vooruit te branden is met OpenVPN, veel te weinig cpu power.

[valkenier]

Het probleem is de source port in WAN_IN. De destination is 1194, maar de source hoeft dat niet te zijn. Deze regel (10) kun je verder geheel weglaten uit WAN_LOCAL als openvpn niet op je edgerouter draait.

[FreddyT]

valkenier schreef op zaterdag 18 februari 2023 @ 14:56:
Het probleem is de source port in WAN_IN. De destination is 1194, maar de source hoeft dat niet te zijn. Deze regel (10) kun je verder geheel weglaten uit WAN_LOCAL als openvpn niet op je edgerouter draait.

Als ik de voorgestelde aanpassing doe (verwijder 1194 uit source voor WAN_IN en verwijder regel (10) uit WAN_LOCAL krijg ik de volgende melding met tcpdump als ik vanaf een computer binnen het netwerk een VPN verbinding wil maken:
22:05:49.392052 IP (tos 0xc0, ttl 64, id 40213, offset 0, flags [none], proto ICMP (1), length 110)
77.xxx.xx.xx > 192.168.2.199: ICMP 77.166.65.71 udp port 1194 unreachable, length 90
IP (tos 0x0, ttl 127, id 42862, offset 0, flags [none], proto UDP (17), length 82)
192.168.2.199.56200 > 77.xxx.xx.xx.1194: UDP, length 54

en zie ik in de OpenVPN log het volgende:
Sat Feb 18 23:06:39 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]77.xxx.xx.xx:1194
Sat Feb 18 23:06:39 2023 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Feb 18 23:06:39 2023 UDP link local: (not bound)
Sat Feb 18 23:06:39 2023 UDP link remote: [AF_INET]77.xxx.xx.xx:1194
Sat Feb 18 23:06:39 2023 MANAGEMENT: >STATE:1676757999,WAIT,,,,,,
Sat Feb 18 23:07:39 2023 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Feb 18 23:07:39 2023 TLS Error: TLS handshake failed
Sat Feb 18 23:07:39 2023 SIGUSR1[soft,tls-error] received, process restarting
Sat Feb 18 23:07:39 2023 MANAGEMENT: >STATE:1676758059,RECONNECTING,tls-error,,,,,
Sat Feb 18 23:07:39 2023 Restart pause, 5 second(s)
Sat Feb 18 23:07:44 2023 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Feb 18 23:07:44 2023 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Feb 18 23:07:44 2023 MANAGEMENT: >STATE:1676758064,RESOLVE,,,,,,
Sat Feb 18 23:07:44 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]77.xxx.xx.xx:1194
Sat Feb 18 23:07:44 2023 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Feb 18 23:07:44 2023 UDP link local: (not bound)
Sat Feb 18 23:07:44 2023 UDP link remote: [AF_INET]77.xxx.xx.xx:1194
Sat Feb 18 23:07:44 2023 MANAGEMENT: >STATE:1676758064,WAIT,,,,,,

En krijg ik geen VPN verbinding.

Als ik vanaf mijn mobiel via 4G een VPN verbinding wil maken zie ik niks met tcpdump.

Er is dus nog steeds iets niet goed......

[valkenier]

Van binnenuit is het maar de vraag of de experiabox nat loopback aankan. Weet ik niet. Van buiten kun je last hebben van je dubbele NAT wellicht? Klopt die forwarding wel naar je EdgeRouter?

[Kabouterplop01]

Hier staat het issue:
77.xxx.xx.xx > 192.168.2.199: ICMP 77.166.65.71 udp port 1194 unreachable, length 90
IP (tos 0x0, ttl 127, id 42862, offset 0, flags [none], proto UDP (17), length 82)
192.168.2.199.56200 > 77.xxx.xx.xx.1194: UDP, length 54

Het punt is bij dubbel NAT (Dubbel NAT is totaal geen probleem, als je weet wat je moet doen) dat je routering stuk is,
Je zult dus moeten routeren.

Hoe ziet je subnet achter je experiabox eruit? En hoe ziet je subnet achter je edgerouter eruit?

[FreddyT]

Kabouterplop01 schreef op zondag 19 februari 2023 @ 13:27:
Hier staat het issue:
77.xxx.xx.xx > 192.168.2.199: ICMP 77.166.65.71 udp port 1194 unreachable, length 90
IP (tos 0x0, ttl 127, id 42862, offset 0, flags [none], proto UDP (17), length 82)
192.168.2.199.56200 > 77.xxx.xx.xx.1194: UDP, length 54

Het punt is bij dubbel NAT (Dubbel NAT is totaal geen probleem, als je weet wat je moet doen) dat je routering stuk is,
Je zult dus moeten routeren.

Hoe ziet je subnet achter je experiabox eruit? En hoe ziet je subnet achter je edgerouter eruit?

Het adres van de Experiabox is 192.168.2.254. De EdgeRouter heeft hier het adres 192.168.2.199. In de ExperiaBox wordt poort 1194 geforward naar het adres van de EdgeRouter (net zoals ik dat voor bijv. poort 80 doe):



In de EdgeRouter (adres 192.168.1.1) wordt poort 1194 geforward naar 192.168.1.111:



De webserver op poort 80 draaiend op dezelfde server als de OpenVPN server is bereikbaar. En dat had ik dus ook verwacht voor poort 1194.

tcpdump output vanuit de EdgeRouter als de webserver wordt aangeroepen:
20:31:01.341641 IP (tos 0x0, ttl 63, id 60730, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.199.80 > 77.xxx.xx.xx.63575: Flags [.], cksum 0x8e4a (correct), ack 429, win 501, length 0
20:31:01.341801 IP (tos 0x0, ttl 62, id 60730, offset 0, flags [DF], proto TCP (6), length 40)
77.xxx.xx.xx > 192.168.2.199.63575: Flags [.], cksum 0x8e4a (correct), ack 429, win 501, length 0

[MasterL]

edit nvm..

[ Voor 94% gewijzigd door MasterL op 20-02-2023 10:28 ]

[MdBruin]

Maak er eens een TCP VPN van i.p.v. de UDP. In het verleden heb ik ook problemen hiermee gehad (had dan wel de OpenVPN op de Edgerouter draaien, maar ik kon geen verbinding maken). Een van de TS'en van het Ubiquiti topic heeft mij toen geholpen en na het veranderen naar een TCP VPN ging het in 1 keer goed. Dit was een combi van de ExperiaBox v8 en de Edgerouter 3 lite, waarom het niet goed ging met de UDP zijn we niet achter gekomen maar voor mij was hierdoor het probleem opgelost.

[Ben(V)]

Laat de firewall wel icmp door?
En heb je in die edgrouter geen rule extra rule nodig voor icmp?

Icmp is noch tcp noch udp maar wordt wel door OpenVpn gebruikt om de connectie op te zetten.

[FreddyT]

MdBruin schreef op maandag 20 februari 2023 @ 15:18:
Maak er eens een TCP VPN van i.p.v. de UDP. In het verleden heb ik ook problemen hiermee gehad (had dan wel de OpenVPN op de Edgerouter draaien, maar ik kon geen verbinding maken). Een van de TS'en van het Ubiquiti topic heeft mij toen geholpen en na het veranderen naar een TCP VPN ging het in 1 keer goed. Dit was een combi van de ExperiaBox v8 en de Edgerouter 3 lite, waarom het niet goed ging met de UDP zijn we niet achter gekomen maar voor mij was hierdoor het probleem opgelost.

Dat was inderdaad de oplossing Inderdaad in 1 keer goed na veranderen in TCP.