So the port is accessible from outside while testing from an external network
user@75.61.90.12 ~$ nc -vuz 1.1.1.1 42005
Connection to 1.1.1.1 42005 port [udp/*] succeeded!
but not when sending the request from internal host part from the 192.168.1.0/24 network. When testing directly to IP where the service is working I got a successful response - both images were attached.
By the way, I try to create the same rules and open access to UDP 1194 the Open VPN port and it works without any problems. I think there is some limitation for the Firewall or not working with all range of ports.
A single firewall rule to allow destination packets to reach server (provided in the default rules setup)
A single source nat rule to keep track of outgoing packets assigned the router WANIP outbound (sourcenat if a fixed IP, masquerate action if a dynamic wanip)
If you wish to access the server from the same subnet the server is on, simply use the LANIP of the server.
If you wish to access the server by using the WANIP of the router (as if you were external) but from the same subnet as the server that is called HAIRPIN NAT and you will need
an xtra source nat rule and will need to modify potentially the destination nat rule (depending upon if WANIP is static or dynamic.
For each server you will need a single destination nat rule
If you can limit the external wanips requiring access to the the server, then use source-address-list in the destination nat rule (this changes port scans from closed to invisible).
As per paragraph 4 above, Hairpin nat is required when people IN THE SAME SUBNET as the server are trying to access the server via the WANIP of the router.
Its much easier to access the server directly by its LANIP address but apparently is not always the case.
What one needs to know is if your WAN connection is dynamic or static?
(1) Regardless of that there is one extra source nat rule for the hairpin functionality that we have to include that works in both cases.
add chain=srcnat action=masquerade src-address=192.168.88.0/24 dst-address=192.168.88.0/24 (replace with the subnet your server and users are on)
(2) For the default or regular source nat rule (use a. masquerade for dynamic wanip, use b. srcnat for static/fixed wanip)
a. add chain=srcnat action=masquerade out-interface=WAN ( I think for ppp0e connection one has to use the out-interface=pppoe-out interface. )
b. add chain=srcnet action=src-nat out-interface=WAN to-address=WANIP
(3) For the required destination nat rule the simple case is for the fixed WANIP since we know its IP.
add chain=dstnat action=dst-nat dst-address=FIXEDWANIP dst-port=80 protocol=tcp
to-addresses=192.168.88.2
(4) For the required destination rule in the complex case wanip dynamic we have to be tricky. Since we don’t know how to identify directly the incoming WANIP, we get around that with the dst-address-type ‘local’ entry, which says the destination address is on the router. We also state that the destination address is not the subnet (which leaves the router interface and thus the wanip).
add chain=dstnat action=dst-nat dst-port=80 protocol=tcp d st-address=!192.168.88.1
dst-address-type=local to-addresses=192.168.88.2
Hi Anav,
And thanks of course for your replay. Yes, I confirm that I using the static IP address on WAN interface. Following your post, the only missing is mentioned in point (1). I think that this rule can be replaced with the default one coming with the base startup-config
All other rules are the same as yours. Here is the example of how the VPN rules are implemented and the internal request to VPN port is accessible and the rules for another service port which is not working
There is no problem when sent request to this port 42005 from the outside (Internet) the traffic passed through the nat rule responsible to deliver the traffic to an internal address correctly but not from the Intranet. The masquerade rule didn’t process any request from LAN via the WAN interface. The problem is that the software always sent a request to real Internet IP like a DNS A record but directly to IP than DNS name. That is because I cannot use internal DNS cache to redirect the request directly to internal IP.
I did the following test by the way. I reconfigured the OpenVPN to listen to 42005 and stop the service which is using this port. And the result is absolutely the same. When the VPN listen to 1194 the traffic from internal subnet via the WAN is passed. When OpenVPN is listening on 42005 nothing happens. Traffic/Packet statistics on the web didn’t count anything. That is because I think there is an issue with the firewall which didn’t work with high range of ports probably.
Hi there, you are doing IPSEC or at least VPN, in the mix. I was addressing straight port forwarding.
I wont even pretend to know how to handle OPEN VPN. Will leave that to others with more knowledge.
My recommendation is to use the other vpn protocols available on the router. IF only ROS7 had wireguard…
I would send toilet paper to Latvia!
Hi Anav,
You are semi right. The OpenVPN is working on internal host behind the router. On the same host is working the service YSF Reflector on port 42005. OpenVPN just gives me a chance to test port 42005 with another application on UDP.
On the router is working only Gre Tunnel with IPSec which access different subnet than this where the OpenVPN and YSF Room is working.
Thats vague.
If the person had created a dst nat rule where the wan interface is dynamic then its perfectly legit to use in-interface-list=wan, however
If the person wants lan users on the same lan interface as the server, to reach the server via the WANIP, then thats a different case and would not use in-interface-list=wan.
Is there a difference if I use in-interface-list=WAN or in-interface=ether1 when in the list WAN exist only ether1. In my case, there is no probably any difference if I use directly static IP in Dst. Address or WAN List as in-interface-list or ethernet port ether1 at in-interface.
I don’t know. It can be the wrong approach.
For dstnat rules, with a fixed wanip, you should NOT use in-interface-list=wan, you should use dst-address.
For dstnat rules with a dynamic wanip, it is okay to use in-interface-list=WAN, except for the case where you want to hairpin nat that server.
For sourcenat rules…
One uses masquerade action for a dynamic wanip with out-interface-list=WAN
One uses src-nat action for fixed wanip with out-interface-list=WAN and to-address=thefixed IP
Thanks a lot, Anav
Based on your explanation I did changes in both dstnat and srcnat rules. Now looks everything works. It looks have to follow strictly the type of interface or address you are using in the rule.
Now the rule looks
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Masquerade Public WAN IP
chain=srcnat action=masquerade out-interface=ether1-tbc log=no log-prefix="" ipsec-policy=out,none
..
16 ;;; FORWARDING to YSF Room
chain=dstnat action=dst-nat to-addresses=192.168.1.10 to-ports=42005 protocol=udp dst-address=94.PUB.INT.ADD connection-mark="" dst-port=42005 log=no log-prefix=""
17 chain=srcnat action=masquerade protocol=udp src-address=192.168.1.0/24 dst-address=192.168.1.10 out-interface=bridge-lan dst-port=42005 log=no log-prefix=""
What about a case where on the WAN is assigned more than one static IP address.
In general, the issue has been resolved for my case.
Thanks one more time
If the wanIPS are dynamic, then the single srcnat masquerade rule out-interface-list=wan should work.
If the wanIPS are static then I suspect you need a single srcnat src-nat rule for each fixed wanip.
