Page 1 of 1

src-nat problem

Posted: Wed Jan 22, 2014 12:18 pm
by dadaniel
I'm using the following firewall rule for the internet connectivity of my internal network, so the src address of outgoing connections is one of my official ips (123.123.123.111).

/ip firewall nat
add action=src-nat chain=srcnat src-address=192.168.0.0/24 to-addresses=123.123.123.111

My problem is that other 123.123.123.xxx adresses can access 192.168.0.x IP Adresses directly. But they should only be able to access 123.123.123.111 and it's dst-nat entries (port forwards).

Here are the logs:

is OK, because NATed:
firewall,info forward: in:ether2-wan1 out:ether5-lan, src-mac 00:0c:29:xx:xx:xx, proto TCP (ACK,PSH), 123.123.123.100:143->192.168.0.171:50681, NAT 123.123.123.100:143->(123.123.123.111:50681->192.168.0.171:50681), len 50
not ok, because access is possible without NAT:
firewall,info forward: in:ether2-wan1 out:ether5-lan, src-mac 00:1b:fc:xx:xx:xx, proto TCP (SYN), 123.123.123.101:49186->192.168.0.111:445, len 52


When I add a firewall rule "drop all from any to 192.168.0.x" in chain forward, I lose internet connection.


Any ideas?

Re: src-nat problem

Posted: Wed Jan 22, 2014 3:19 pm
by patrickmkt
can you show us your firewall rules in order?

Re: src-nat problem

Posted: Thu Jan 23, 2014 5:30 pm
by dadaniel
/ip firewall address-list
add address=123.123.123.108/28 list=ournetwork
add address=192.168.0.0/24 list=ournetwork

/ip firewall filter
add action=drop chain=forward connection-state=invalid
add chain=input in-interface=ether5-lan
add chain=input connection-state=established
add chain=input connection-state=related
add chain=input comment="Winbox" dst-port=8291 protocol=tcp
add chain=input comment="Bandwidth Test Server" dst-port=2000 protocol=tcp
add chain=input comment="Bandwidth Test Server" dst-port=2000-2100 protocol=udp
add action=drop chain=forward comment="stop IP Spoofing" in-interface=!ether5-lan src-address=192.168.0.0/24
add action=drop chain=forward comment="stop IP Spoofing" in-interface=!ether2-wan1 src-address=123.123.123.108/28
add action=drop chain=input

/ip firewall nat
add action=src-nat chain=srcnat src-address=192.168.0.0/24 to-addresses=123.123.123.111
add action=dst-nat chain=dstnat dst-address=123.123.123.111 dst-port=88 protocol=tcp to-addresses=192.168.0.201 to-ports=88
add action=dst-nat chain=dstnat dst-address=123.123.123.111 dst-port=89 protocol=tcp to-addresses=192.168.0.202 to-ports=80
add action=dst-nat chain=dstnat dst-address=123.123.123.111 dst-port=90 protocol=tcp to-addresses=192.168.0.203 to-ports=90
add action=dst-nat chain=dstnat dst-address=123.123.123.111 dst-port=3389 protocol=tcp to-addresses=192.168.0.110 to-ports=3389

Re: src-nat problem

Posted: Thu Jan 08, 2015 7:27 am
by SoundGuyFYI
This sounds more like a routing/firewall issue. Have you figured it out?

If not then what are your routes? are you distributing routes using a EGP of any kind into the public network? If the internal IP addresses are in a seperate network then they are being routed to it. That means that something is tell the computer that it should go to your public IP to get to those private IPs.

If you are still having issues, post your routes here and any EGPs you might have aswell.

Re: src-nat problem

Posted: Fri Jan 09, 2015 12:08 am
by docmarius
I would use some forward filters, also with specific ports:
/ip firewall filter
add chain=forward comment="outgoing" in-interface=ether5-lan out-interface=ether2-wan1
add chain=forward comment="established" connection-state=established in-interface=ether2-wan1 out-interface=ether5-lan
add chain=forward comment="related" connection-state=related in-interface=ether2-wan1 out-interface=ether5-lan
add action=drop chain=forward comment="Drop the rest"
and make sure you have connection tracking enabled.
This will enable outgoing connections, bot no connections originating on the outside, except those allowed by the dst-nat rules.

The forward drop you suggested does not work because it will drop the return packets from the internet, which match that same rule.

In your configuration, the incoming connections are possible, since, unless a clear drop forward rule is in place, the router will still forward the incoming connection, without NAT, to the proper recipient, according to its routing tables. But it will route nevertheless.

To avoid such unintuitive behavior, best practice is to have a explicit "drop all" (or "allow all" e. g. on the output chain) at the end of each chain rule set (as in the example above).