I am experiencing some weird issues at the moment, we have a setup as below:
On the RB750s we have the following NAT rule in place:
0 ;;; Network NAT
chain=srcnat action=masquerade out-interface=Port 1 - WAN
Whenever we run a torch on the on the RB1100 eth1 we are seeing the following traffic:
192.168.1.x/24 ranges and 10.1.1.x/24 ranges, this should be natted to the 1.1.1.2 address and 2.2.2.2 address.
If I connect behind one of the RB750 and browse the internet my local range IP is been natted to the correct public IP, I cannot figure out for the life of me why the RB1100 is seeing this local range traffic, any ideas??
One 750 connects to eth01 and the other connects to eth02, correct?
What is the WAN port on the 1100?
And that is just a typo that the 1100 and the 750 have the same ip. The 1100 eth02 is 2.2.2.1/30, right?
No “arp=proxy-arp” on the 750 ethernet ports?
If both connect to eth01, then both need the eth01 subnet. How do you have the second router (2.2.2.2/30) set up in “/ip route”? How do you have the 1100 set to send 2.2.2.2 traffic out the 1.1.1.1 interface?
This would be my setup:
The 1100 eth1 would be 1.1.1.1/28
750 #1 would be 1.1.1.2/28
750 #2 would be 1.1.1.3/28
Both 750 default gateways would be:
/ip route
add gateway=1.1.1.1
EDIT: Does your internet connection device (cable/dsl modem) connect to the switch?
Would changing the set up of the network as above sort the issue? I should of expanded the diagram slightly as to say we have other routes on the network connecting to the switch. We have several draytek routers connecting back to the RB1100 which are showing their WAN side IP only in the torch.
It is going to cure part of it. You have three subnets showing on that interface (with torch) that shouldn’t be there, and one is the 2.2.2.x subnet. It is already assigned to eth02 in the 1100. That will cause some routing problems. If you have other devices on that switch, they should all be 1.1.1.x subnet. BTW, I use the 10.x.x.x and 192.168.x.x subnets for internal networks.
You can assign multiple ip subnets to that interface, but I recommend keeping it simple, especially if you are doing another NAT (srcnat or masquerade) at the WAN interface on the 1100. I route my networks rather than NAT.
We are seeing a very similar problem on our network - internal IP’s showing up on the WAN side of the network, http and https only.
The LAN side of our network is dhcp. All our clients get a 10.25.x.x/16 ip address, all our gear (wireless client bridges) is on a 169.254.x.x/16 address (static assignents, not assigned by RouterOS)
On the WAN side of the network we have a block of 16 routable IP’s. We use masquerade for our regular clients, and one-to-one NAT for special case clients.
Torch on the WAN port shows 10.25.x.x addresses, and sometimes a 192.168.1.x address, which is really wierd as we don’t use that range for anything.
Is it our statically assigned 169.254 devices that are confusing the router?
Are you certain the traffic is originating inside your network? I show 10.2.x.x addresses on my ether1 port, and I have no 10.2.x.x networks on this device. But my ISP does have those ips on my wan localnet, and I can ping them.
/tool sniffer
set interface=ether1
start
(wait a minute)
stop
/tool sniffer host print
I’d have to check with my internet provider, but I don’t think it’s there ips, as they are the ones that contacted me about it. Apparently it’s confusing their load balancer to have my private IP’s on the WAN port.
Check with your ISP. Ask if they have a 10.25.200.x net on your wan interface. I have 10.2.144.1 on my wan. It is the Cox Communications router between Miramar Beach and Destin. My first hop on a traceroute to anywhere.
Try pinging 10.25.200.185. The icmp traffic will show over ether1. That means 10.25.200.185 is on your wan interface. Your ISP.
ADD: They probably have residential dhcp clients on that connection also. The 255.255.255.255 address in your list is a giveaway. That is a dhcp request ip. They just forward (route) your public ip through their private net.
If that is not enough to convince you, connect a computer directly to your ISP. Set it for dhcp instead of static. I will bet it gets a 10.25.200.x address.
Sorry about the delayed response, things got crazy for a bit. Anyway…
I checked with my ISP, they don’t use that IP range on their network.
Interestingly, my router died a while later. I replaced it with a routerboard 750G running ROS 4.5. At the same time I changed my internal IP address range from 10.25.200.x to 10.25.0.x.
Now I"m seeing traffic from 10.25.0.x addresses on the WAN port of my new router.
I also put in an identical router type and OS on my personal network - hooked up via DHCP to a different ISP, I"m seeing internal IPs on the WAN port of that one as well - http, bootps and boot pc (255.255.255.255)
Am I perpetually configuring something improperly, and carrying this mistake onto all my routers?
Where is your wan (internet connection) interface?
Maybe if you post “/ip firewall nat” would help.
This gets a little confusing with two sets of configurations here. It would be best if you start your own thread next time.
Where is your wan (internet connection) interface?
Maybe if you post “/ip firewall nat” would help.
This gets a little confusing with two sets of configurations here. It would be best if you start your own thread next time.
My apologies to the origonator of this thread. I meant to put in my own two cents, not take over.
Anyway, My WAN interface is ether 1- gateway, connected directly into the cable modem provided by my ISP
Inbound Scan
Typically this traffic is related to normal DHCP operation and is not an attack on your network. DHCP (Dynamic Host Configuration Protocol) is how your computer gets its unique IP address. When a system starts up on a network it must first request an IP address (assume it is not using a static IP address), and it does this by broadcasting a request to the DHCP server:
UDP 0.0.0.0:68 → 255.255.255.255:67
since the requesting system doesn’t have an IP address (why it is asking) it uses 0.0.0.0 and since its new to the network it doesn’t know where the DHCP server is, so it broadcasts the request to the entire network (255.255.255.255). On some networks you will see these requests bounce off of your firewall (depending on your provider’s network configuration and if your router/firewall logs these requests), or your firewall/router might log this traffic between it and your providers DHCP server when it is getting or renewing its WAN IP address.
The DHCP server then responds with something like:
UDP 192.168.1.1:67 → 255.255.255.255:68
This is typically a DHCP offer. NOTE it has to be broadcasted (255.255.255.255) as the requesting system doesn’t yet have an IP address (its contained in the offer). The data in this transmission contains the IP and other network configuration information that the requesting system needs to connect to the network (lease time, Subnet Mask, etc). Again on some networks you will see these bounce off of your firewall (depending on your provider’s network configuration and if your router/firewall logs these), or your firewall/router might log this traffic between it and your providers DHCP server when it is getting or renewing its WAN IP address.
Sometimes you will see something like:
UDP 192.168.1.101:67 → 192.168.1.1:68
as a request, followed by a reply
UDP 192.168.1.1:68 → 192.168.1.101:67
These are typically IP renewal requests, where a system has an IP address and is asking to renew it (ie get the lease extended), or if its not possible to renew the IP address to receive a new IP address from the DHCP server. Since the requesting system knows where the DHCP server is and it already has a current IP address the requests don’t need to use 0.0.0.0 and 255.255.255.255.
Outbound Scan
Most routers/firewalls don’t log this traffic, but given most routers/firewalls are also the local DHCP server you might see traffic logged between your router/firewall and connecting systems as they ask for and are assigned an IP Address on your network. It is not common to have your DHCP server on the WAN side of your firewall so in those cases perhaps you should investigate the configuration of your network.
