Sorry if this was posted twice - my 1st posting did not show up in the forum.
want sample client config that does not leak RFC-1918 IPs
Quick background: I am a WISP with hundreds and hundreds of clients. I am switching all new customer CPE equipment to Mikrotik boards ( RB411 - crossroads - RB433AH…)
My network hands out live WAN IP addrsses to my Mikrotik client radios.
My client Mikrotik ethernet interfaces use 192.168.56.x/24 (clients gateway to 192.168.56.1)
I use IP-Firewall-NAT srcnat to on each client CPE device. When a client computer talks to the Internet, their IP is mapped to the live-outside-address of the WAN on the CPE.
I use Simple Queues to limit customer up and down bandwidth.
The customer Mikrotik CPE is also a dhcp server for the customer LAN
I am testing various IP-Firewall-FilterRules to totally block all RFC-1918 leaks - have huge problem here…
I use a Cisco core router in my NOC which uses IOS access-lists
I have found that ALL my Mikrotik CPE clients leak RFC-1918 IP traffic to the Internet. I would like to ask - does anybody have a a sample client CPE mikrotik (station with up & down bandwidth control) configuration anywhere which I can look at and test which does not leak RFC-1918. ???
My Cisco access-lists do catch the RFC-1918 leaks - but these Mikrotik client CPE RFC-1918 leaks are tying up air-time and filling up my Cisco logs.
I have looked and tried and tested for months and I can not stop the RFC-1918 leaks.
customer wireless CPE station - Live IP assigned to the wireless WAN - Client ethernet network uses 192.168.56.x/24. I use 192.168.56.x/24 on the client ethernet to allow the customer to add additional nat devices which may use 192.168.0.x or 192.168.1.x devices further inside their network.
This is a typical client CPE ip-firewall config I am testing/using. Note - not all the lines below are enabled. The non-enabled lines will cause the client CPE to quit working if I turn them on.
note - I bridge WAN and wlan together and bridge LAN and ether1 together
I am not strong on this - but this is what I have:
In my core Cisco router - I use access-lists to block RFC-1918 to & from WISP CPE devices. My logs fill up with this stuff: Oct 5 08:59:32.626: %SEC-6-IPACCESSLOGP: list 147 denied tcp 192.168.56.102(1032) (Vlan202 000c.4239.c360) → 65.54.95.176(80), 1 packet
Oct 5 08:59:52.150: %SEC-6-IPACCESSLOGP: list 147 denied tcp 192.168.56.120(51129) (Vlan202 000c.4239.ec84) → 216.115.100.103(80), 7 packets
Oct 5 08:59:52.150: %SEC-6-IPACCESSLOGP: list 147 denied tcp 192.168.56.120(51130) (Vlan202 000c.4239.ec84) → 216.115.100.103(80), 7 packets
Oct 5 08:59:52.150: %SEC-6-IPACCESSLOGP: list 147 denied tcp 192.168.56.120(51128) (Vlan202 000c.4239.ec84) → 216.115.100.103(80), 6 packets
Oct 5 08:59:52.150: %SEC-6-IPACCESSLOGP: list 147 denied tcp 192.168.56.120(51109) (Vlan202 000c.4239.ec84) → 216.115.100.103(80), 6 packets
Oct 5 09:00:02.574: %SEC-6-IPACCESSLOGP: list 147 denied tcp 192.168.56.102(1033) (Vlan202 000c.4239.c360) → 65.54.95.176(80), 1 packet
note - cisco access-list 147 is blocking RFC-1918 traffic in from client CPEs heading out to the Internet.
note - the live IPs shown in the list above are not MY IPs - they are real IPs that my customer CPEs are trying to talk to but the NAT is leaking.
Does somebody have a sample IP-firewall filter config I can take a look (modify if necessary) and and try?
On the way from the WAN to the LAN source NAT has been undone by the time packets are in the forward chain, so dropping traffic to 192.168.0.0/16 with an out-interface equal to LAN means you’re dropping all traffic to the CPE. However, source NAT also doesn’t happen until after postrouting so you can’t drop 192.168.0.0/16 with an out-interface equal to WAN in the forward chain as that drops all traffic from the LAN to the WAN.
The advice to drop invalid packets is rather literal:
Only invalid packets should ever be evading source NAT and make it through un-NAT’d because as long as the connection can be tracked statefully source NAT will capture it, so dropping those packets - which are no use to anyone, anyway, as they are invalid - should prevent them from making it through to your Cisco router. Insert that rule high up in the forward chain. In fact, you can save a whole lot of work and filter statefully by pushing this to the top of your forward chain:
Once a connection has been permitted and established you might as well accept it as early as possible - if it was OK to establish the connection, all further packets belonging to the connection are also OK.
Edit: crosspost with mrz. His link shows more details.
I think this is working correctly. I added 3 additional lines to the configuration.
/ip firewall filter
add action=accept chain=forward comment=“Accept packet which belongs to an existing established connection” connection-state=established disabled=no
add action=accept chain=forward comment=“Accept packets which are related to but not part of an existing connection. Example ICMP errors - packets which begins FTP data connection” connection-state=related disabled=no
add action=drop chain=forward comment=“Drop invalid packets which could not be identified for some reason” connection-state=invalid disabled=no
add action=drop chain=forward comment=“block traffic to 10.0.0.0/8 from cust(WORKS)” disabled=no dst-address=10.0.0.0/8 in-interface=LAN
add action=drop chain=forward comment=“block traffic to 172.16.0.0/12 from cust(WORKS)” disabled=no dst-address=172.16.0.0/12 in-interface=LAN
add action=drop chain=forward comment=“block traffic to 192.168.0.0/16 from cust(WORKS)” disabled=no dst-address=192.168.0.0/16 in-interface=LAN
/
Note to all readers - this is for my client devices which get a live Internet IP address on the WAN/wireless card and nat to 192.168.56.x/24 for the LAN/ethernet1
I first tested this ip-firewall-filter rule using just the first three lines alone. I found that customers who use nat devices behind my natted LAN/ethernet were still horribly leaking RFC-1918 traffic. For example, my LAN/ethernet1 uses 192.168.56.x/24 but the customer Mikrotik was still trying to pass packets to the Internet to 192.168.0.x and 192.168.1.x (along with some 10.0.0.0/8 stuff and 172.16.0.0/12 stuff).
I then added the bottom 3 additional lines in my ip-firewall-filter rules and all RFC-1918 traffic has totally stopped now. Prior to these filter commands on a typical average day I would daily average 1,200 to 20,000 RFC-1918 packets from all my Mikrotk CPE clients. As of these filter rules I just addes I now see zero RFC-1918 leaks from customer CPEs to the Internet.
I suspect this will help clean up air time for more valid traffic to & from my clients.