Hello Guys,
Modell: Atheros AR9330 rev 1
OpenWrt 19.07.7
We have OpenVPN Client configured to connect to our Datacenter.
Now we want to access some devices behind the OpenWRT Router.
Source Datacenter, Destination Device behind Router
So we need magic DNAT 
We configured it and it is working as exceptet.
We can Access severla HTTPS Pages etc...
BUT only SSH (22) is not working.
See picture.
We also have a snat rule.
Does anybody can tell my why?!
Greetings Michael
You don't need udp for ssh, http, https.
There is no protocol defined in the last rule, maybe IP/222 is used.
Post here the output of iptables-save -c -t nat
oh yes. i fxed it, but still have the problem.
here the ouput
# Generated by iptables-save v1.8.3 on Wed Jun 9 09:05:14 2021
*nat
:PREROUTING ACCEPT [8:602]
:INPUT ACCEPT [7:364]
:OUTPUT ACCEPT [17:1396]
:POSTROUTING ACCEPT [0:0]
:GL_SPEC_DMZ - [0:0]
:postrouting_guestzone_rule - [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_guestzone_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_guestzone_postrouting - [0:0]
:zone_guestzone_prerouting - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_ovpn_postrouting - [0:0]
:zone_ovpn_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
[9:654] -A PREROUTING -j GL_SPEC_DMZ
[9:654] -A PREROUTING -m comment --comment "!fw3: Custom prerouting rule chain" -j prerouting_rule
[8:602] -A PREROUTING -i br-lan -m comment --comment "!fw3" -j zone_lan_prerouting
[0:0] -A PREROUTING -i eth0 -m comment --comment "!fw3" -j zone_wan_prerouting
[0:0] -A PREROUTING -i wwan0 -m comment --comment "!fw3" -j zone_wan_prerouting
[0:0] -A PREROUTING -i br-guest -m comment --comment "!fw3" -j zone_guestzone_prerouting
[1:52] -A PREROUTING -i tun0 -m comment --comment "!fw3" -j zone_ovpn_prerouting
[20:1616] -A POSTROUTING -m comment --comment "!fw3: Custom postrouting rule chain" -j postrouting_rule
[1:52] -A POSTROUTING -o br-lan -m comment --comment "!fw3" -j zone_lan_postrouting
[0:0] -A POSTROUTING -o eth0 -m comment --comment "!fw3" -j zone_wan_postrouting
[19:1564] -A POSTROUTING -o wwan0 -m comment --comment "!fw3" -j zone_wan_postrouting
[0:0] -A POSTROUTING -o br-guest -m comment --comment "!fw3" -j zone_guestzone_postrouting
[0:0] -A POSTROUTING -o tun0 -m comment --comment "!fw3" -j zone_ovpn_postrouting
[0:0] -A zone_guestzone_postrouting -m comment --comment "!fw3: Custom guestzone postrouting rule chain" -j postrouting_guestzone_rule
[0:0] -A zone_guestzone_prerouting -m comment --comment "!fw3: Custom guestzone prerouting rule chain" -j prerouting_guestzone_rule
[1:52] -A zone_lan_postrouting -m comment --comment "!fw3: Custom lan postrouting rule chain" -j postrouting_lan_rule
[1:52] -A zone_lan_postrouting -m comment --comment "!fw3: SNAT" -j SNAT --to-source 10.22.1.4
[8:602] -A zone_lan_prerouting -m comment --comment "!fw3: Custom lan prerouting rule chain" -j prerouting_lan_rule
[1:52] -A zone_ovpn_prerouting -p tcp -m tcp --dport 122 -m comment --comment "!fw3: ESX SSH" -j DNAT --to-destination 10.22.1.2:22
[0:0] -A zone_ovpn_prerouting -p tcp -m tcp --dport 80 -m comment --comment "!fw3: Router" -j DNAT --to-destination 10.22.1.4:80
[0:0] -A zone_ovpn_prerouting -p tcp -m tcp --dport 443 -m comment --comment "!fw3: ESX HTTPS" -j DNAT --to-destination 10.22.1.2:443
[0:0] -A zone_ovpn_prerouting -p tcp -m tcp --dport 1443 -m comment --comment "!fw3: ILO" -j DNAT --to-destination 10.22.1.3:443
[0:0] -A zone_ovpn_prerouting -p tcp -m tcp --dport 4444 -m comment --comment "!fw3: Firewall" -j DNAT --to-destination 10.22.1.1:4444
[0:0] -A zone_ovpn_prerouting -p tcp -m tcp --dport 222 -m comment --comment "!fw3: Firewall SSH" -j DNAT --to-destination 10.22.1.1:22
[19:1564] -A zone_wan_postrouting -m comment --comment "!fw3: Custom wan postrouting rule chain" -j postrouting_wan_rule
[19:1564] -A zone_wan_postrouting -m comment --comment "!fw3" -j MASQUERADE
[0:0] -A zone_wan_prerouting -m comment --comment "!fw3: Custom wan prerouting rule chain" -j prerouting_wan_rule
COMMIT
````Preformatted text`
Please use the "Preformatted text </>" button for logs, scripts, configs and general console output.
Please edit your post accordingly. Thank you! 
There is a hit here, so you may want to check the esx why it didn't reply.
There are no hits here. If 10.22.1.1 is the OpenWrt itself you'd better create a rule to accept the ssh directly, rather than adding extra cycles to the cpu with dnat.
No need for DNAT since you can set up a site-to-site connection:
https://openwrt.org/docs/guide-user/services/vpn/openvpn/extras#site-to-site
And it can be even better if you replace OpenVPN with WireGuard:
https://openwrt.org/docs/guide-user/services/vpn/wireguard/start
Hello,
that is not possible.
We only can use OVPN 
NAT
the openwrt router is at the customers side and we don't want to route our internal networks.
done
the hit on 10.22.1.1 ist not possible at the moment (system down)
The esx ssh ist working correctly.
When i connect directly to the server ssh is fine...
And as you see it is the same subnet. ther should not be any routing issues..
any other ideas?
As long as OpenWrt is concerned, the packet was forwarded to the 10.22.1.2:22
Setup a packet capture on the ESX to verify that you can see the packet.
ok you are right. i can see the package
tcpdump-uw: listening on vmk1, link-type EN10MB (Ethernet), capture size 262144 bytes
10.22.1.4.63610 > ESX1.ssh: Flags [SEW], cksum 0x0a89 (correct), seq 2251009927, win 8192, options [mss 1286,nop,wscale 8,nop,nop,sackOK], length 0
ESX1.ssh > 10.22.1.4.63610: Flags [S.E], cksum 0x1658 (incorrect -> 0xc8a1), seq 1549731575, ack 2251009928, win 65535, options [mss 1286,nop,wscale 9,sackOK,eol], length 0
10.22.1.4.63610 > ESX1.ssh: Flags [.], cksum 0x0707 (correct), ack 1, win 256, length 0
ESX1.ssh > 10.22.1.4.63610: Flags [P.], cksum 0x1661 (incorrect -> 0x43c1), seq 1:22, ack 1, win 128, length 21
10.22.1.4.63610 > ESX1.ssh: Flags [P.], cksum 0x10d3 (correct), seq 1:29, ack 1, win 256, length 28
ESX1.ssh > 10.22.1.4.63610: Flags [P.], cksum 0x1854 (incorrect -> 0xfc6f), seq 22:542, ack 29, win 128, length 520
10.22.1.4.63610 > ESX1.ssh: Flags [P.], cksum 0x3510 (correct), seq 1285:1365, ack 542, win 254, length 80
ESX1.ssh > 10.22.1.4.63610: Flags [.], cksum 0x1658 (incorrect -> 0x5976), ack 29, win 128, options [nop,nop,sack 1 {1285:1365}], length 0
As you see there are errors.
direct connet works fine.
Is it possible that there is a problem with the TCP Packages
mtu or somthing else.
it is so weired.
I suspect it is some problem of ESX. Try to forward SSH to a different device.
Sorry for delay.
i tried several ssh devices. it is the same.
it looks like that is a problem with the ssh protocol via vpn and dnat.
If the OpenVPN is using TCP, try with UDP.
already tried udp and tcp
with an without compression
i think maybe posting your question in an esxi forum may lead to faster resolution... it's not the first time such issues have cropped up... but please come back and let us all know the outcome...
hi @all.
the problem was, that we had fragmented tcp packages over the vpn tunnel.
after a I fixed it, everything works fine
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.