search

aparcar / openwrt

Staging tree of Paul Spooren
Other
9 stars 1 forks source link

FS#1334 - port forwarding not working #1157

Closed aparcar closed 6 years ago

aparcar commented 6 years ago

robertmuth:

TP-Link Archer C7 v2 LEDE Reboot SNAPSHOT r5464-5a8e9846af / LuCI Master (git-17.342.53118-6d086bf)

Steps to reproduce:

I un-systematically tried other lede versions - none of which worked.

aparcar commented 6 years ago

jow-:

Please provide your /etc/config/firewall or a screenshot of your LuCI portforward page.

aparcar commented 6 years ago

robertmuth:

cat /etc/config/firewall

config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT'

config zone option name 'lan' list network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT'

config zone option name 'wan' list network 'wan' list network 'wan6' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1'

config forwarding option src 'lan' option dest 'wan'

config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4'

config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT'

config rule option name 'Allow-IGMP' option src 'wan' option proto 'igmp' option family 'ipv4' option target 'ACCEPT'

config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fc00::/6' option dest_ip 'fc00::/6' option dest_port '546' option family 'ipv6' option target 'ACCEPT'

config rule option name 'Allow-MLD' option src 'wan' option proto 'icmp' option src_ip 'fe80::/10' list icmp_type '130/0' list icmp_type '131/0' list icmp_type '132/0' list icmp_type '143/0' option family 'ipv6' option target 'ACCEPT'

config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'

config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'

config rule option name 'Allow-IPSec-ESP' option src 'wan' option dest 'lan' option proto 'esp' option target 'ACCEPT'

config rule option name 'Allow-ISAKMP' option src 'wan' option dest 'lan' option dest_port '500' option proto 'udp' option target 'ACCEPT'

config include option path '/etc/firewall.user'

config include 'miniupnpd' option type 'script' option path '/usr/share/miniupnpd/firewall.include' option family 'any' option reload '1'

config include 'bcp38' option type 'script' option path '/usr/lib/bcp38/run.sh' option family 'IPv4' option reload '1'

config redirect option target 'DNAT' option src 'wan' option dest 'lan' option dest_ip '192.168.1.111' option name 'ssh3' option reflection '0' option proto 'tcp' option src_dport '8877' option dest_port '8877'

aparcar commented 6 years ago

robertmuth:

Note sure if these experiments done from inside the router are meaningful, but the problem also occurs when coming from the outside:

wget http://192.168.1.111:8877 --2018-02-08 01:06:24-- http://192.168.1.111:8877/ Connecting to 192.168.1.111:8877... connected. HTTP request sent, awaiting response... 200 OK Length: 2711 (2.6K) [text/html] Saving to: 'index.html'

index.html 100%[==================================>] 2.65K --.-KB/s in 0s

2018-02-08 01:06:24 (45.3 MB/s) - 'index.html' saved [2711/2711]

BUT:

wget http://---wan-ip---:8877 --2018-02-08 01:08:01-- http://---wan-ip---:8877/ Connecting to ---wan-ip---:8877... failed: Connection refused.

aparcar commented 6 years ago

arjendekorte:

Remove the line

option src_dport '8877'

from your redirect rule. It is unrealistic to expect that web clients connect from port 8877 when they make a connection to port 8877 unless you specifically tell them to do that (which you probably don't).

aparcar commented 6 years ago

jow-:

Is the target server (192.168.1.111) using your router as default gateway?

aparcar commented 6 years ago

robertmuth:

Re: Arjen de Korte

good catch! I am really trying to forward ssh from 2222->22 but switch to a web server for debugging. I must have messed things up when editing the forwarding rule. (It is confusing to have 3 ports involved of which only 2 are exposed in the guys and all have similar names.) I added another rule to firewall so that we have: But it still does not work.

config redirect option target 'DNAT' option src 'wan' option dest 'lan' option dest_ip '192.168.1.111' option name 'ssh3' option reflection '0' option proto 'tcp' option dest_port '8877' option src_port '8877'

config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp udp' option name 'Ssh ' option dest_ip '192.168.1.111' option src_dport '8877' option dest_port '8877'

aparcar commented 6 years ago

robertmuth:

RE: Jo-Philipp Wich

You could be on to something here The machine 192.168.1.111 also has another IP 192.168.0.111 and it uses the default gateway 192.168.0.1 which goes through another router "B" which then goes through 192.168.0.1 (including double NATing)

On that machine I have: cat /etc/network/interfaces

auto lo iface lo inet loopback

auto eth0 iface eth0 inet static address 192.168.0.111 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.1 dns-nameservers 8.8.8.8

auto enp4s0f0 iface enp4s0f0 inet static address 192.168.1.111 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255

However, for debugging I have also set up port forwarding on router B. In my desperate attempts to get things to work, that router is running and older version of openwrt: 'OpenWrt Chaos Calmer 15.05.1'

Same problem:

internally

wget http://192.168.0.111:8877 --2018-02-08 07:22:28-- http://192.168.0.111:8877/ Connecting to 192.168.0.111:8877... connected. HTTP request sent, awaiting response... 200 OK Length: 2711 (2.6K) [text/html] Saving to: ‘index.html.1’

index.html.1 100%[==================================================>] 2.65K --.-KB/s in 0s

2018-02-08 07:22:28 (336 MB/s) - ‘index.html.1’ saved [2711/2711]

externally (192.168.1.116 is router B's wan IP):

wget http://192.168.1.116:8877 --2018-02-08 07:24:22-- http://192.168.1.116:8877/ Connecting to 192.168.1.116:8877... ^C hangs

aparcar commented 6 years ago

jow-:

That setup will not work. You must ensure that the host your forward traffic to responds directly and not via another (natting) machine - this will lead to unexpected response packets which will get discared at the router.

You have two possibilities to fix the issue.

1) change the default route of the server to use the natting router 2) rewrite the source IPs of both the incoming connection and the response connection

To implement solution #2 you need two additional SNAT rules to complement the DNAT.

The first SNAT rule rewrites the source ip of incoming wan traffic to the routers internal LAN ip, so forwarded traffic hitting the internal server will appear to come from the router itself which will cause the server to respond to the router directly instead of using the default route.

The second SNAT rule rewrites response traffic from the lan server destined to the router back to the routers wan IP where the stateful connection tracking will take care of routing the packets to the original remote client.

In my example below, the both SNAT rules use the IP address of the LAN server as well as the protocol and port number to identify traffic needing rewrites. To avoid rewriting internal LAN traffic using this particular port, a negated subnet match is used to exclude the LAN range.

The rules use symbolic interface notation for the src_dip parameters, which will cause the firewall to automatically resolve the associated IP addresses; which is especially important for the dynamic WAN ip.

config redirect option name 'Port forward wan-ip:2222 to lan-server:22' option src wan option dest lan option proto tcp option dest_ip 192.168.1.111 # IP of the LAN server option src_dport 2222 # external WAN port option dest_port 22 # internal LAN server port option reflection 0 option target DNAT

config redirect option name 'Rewrite request src ip to router lan ip' option src wan option dest lan option proto tcp option src_ip '!192.168.0.0/16' # did not came from private LAN range option dest_ip 192.168.1.111 # is destined to internal LAN server address option dest_port 22 # is destined to internal LAN server port option src_dip lan # rewrite src IP to current address of "lan" interface option target SNAT

config redirect option name 'Rewrite response src ip to router wan ip' option src lan option dest lan option proto tcp option src_ip 192.168.1.111 # came from internal LAN server address option src_port 22 # came from internal LAN server port option dest_ip '!192.168.0.0/16' # is not destined to private LAN range option src_dip wan # rewrite src IP back to current address of "wan" interface option target SNAT

Downside of this approach is that you loose the information about the actual foreign client IP on the LAN server, so anti-bruteforce measures like fail2ban are useless since all requests will appear to come from the router itself.

aparcar commented 6 years ago

robertmuth:

changing the default route did the trick.

I really appreciate your prompt help!