You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expect to be able to forward ports from the VPS to the local network easily.
Current Behavior
Port forwarding on the router side works. In fact, the VPN also works to the point that I can connect to the service behind the router from the VPS side, but it doesn't work for requests sent to the VPS from outside.
OpenMPTCProuter VPS provider: Something regional, you wouldn't know it
OpenMPTCProuter platform: Linux 6.1.0-23-amd64 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 x86_64
Configuration
Ok, so port forwarding was set up as follows:
IPs
192.168.3.1: is OpenMPTCProuter
192.168.3.101: is the destination for the port forwarding, it is another router that passes down the data 2 more levels to reach the actual device. but that won't matter as the rest of the way is configured properly, opening 192.168.3.101:13000 works as expected.
Diagnostic
/etc/shorewall/rules
DNAT net vpn:$OMR_ADDR tcp 13000-13010 # OMR openmptcprouter redirect router 13000-13010 port tcp
DNAT net vpn:$OMR_ADDR udp 13000-13010 # OMR openmptcprouter redirect router 13000-13010 port udp
It seems to me that the service does respond to the initial OpenMPTCProuter.lan.14561 > 192.168.3.101.13000 with a 192.168.3.101.13000 > OpenMPTCProuter.lan.14561 in both examples, but it was passed to tunnel on one case and was ignored on the other. so the response to the request never reached the VPS as it never entered into the tunnel interface. Is this the result of a NAT rule missing on the VPS side to change the source address maybe?
The text was updated successfully, but these errors were encountered:
Expected Behavior
Expect to be able to forward ports from the VPS to the local network easily.
Current Behavior
Port forwarding on the router side works. In fact, the VPN also works to the point that I can connect to the service behind the router from the VPS side, but it doesn't work for requests sent to the VPS from outside.
Specifications
Configuration
Ok, so port forwarding was set up as follows:


IPs
192.168.3.1
: is OpenMPTCProuter192.168.3.101
: is the destination for the port forwarding, it is another router that passes down the data 2 more levels to reach the actual device. but that won't matter as the rest of the way is configured properly, opening192.168.3.101:13000
works as expected.Diagnostic
/etc/shorewall/rules
/etc/shorewall/params.vpn
nc 10.255.255.2 13000
on VPS - WORKSnc 192.168.3.101 13000
on OpenMPTCProuter - WORKStcpdump -i tun0 port 13000
on OpenMPTCProuter withnc 10.255.255.2 13000
on VPS - WORKStcpdump -i eth0 port 13000
on OpenMPTCProuter withnc 10.255.255.2 13000
on VPS - WORKSnc [VPSIP] 13000
on another remote device - FAILS WITH NO RESPONSEtcpdump -i tun0 port 13000
on OpenMPTCProuter withnc [VPSIP] 13000
on another remote device - FAILS WITH NO RESPONSEtcpdump -i eth0 port 13000
on OpenMPTCProuter withnc [VPSIP] 13000
on another remote device - FAILS WITH NO RESPONSEIt seems to me that the service does respond to the initial
OpenMPTCProuter.lan.14561 > 192.168.3.101.13000
with a192.168.3.101.13000 > OpenMPTCProuter.lan.14561
in both examples, but it was passed to tunnel on one case and was ignored on the other. so the response to the request never reached the VPS as it never entered into the tunnel interface. Is this the result of a NAT rule missing on the VPS side to change the source address maybe?The text was updated successfully, but these errors were encountered: