Router is forwarding broadcast messages? Challange :)

***CHALLENGE***

ISSUE: ...
'My Router/firewall is forwarding broadcast messages!?'

Please try and think why and when a router or a firewall would forward a broadcast message or a packet destined to a broadcast address? We learn that these devices do not do that.

Topology (simplified for now):

Host

>R1

>R2--->ISP

Host is 192.168.201.9/24

REAL LOG R2 Router:
Deny udp src inside:192.168.201.9/137 dst outside:192.168.201.255/137

Please suggest an explanation and a solution to fix it. It might require skills beyond CCNA. Give it a try! I do not expect a complete solution, ideas are good enough

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Magic Johnson

Well routers can pass on DHCP messages using the ip helper command, which is sent as a broadcast?

Beyond that though I had to resort to Google and found some interesting stuff, think it ties in with the log you've been given too.

mk01

Nice try but I can send an icmp message as well:

R1 showing a message has been sent to R2

ccna-labs-kickstarter-broadcast1.jpg

bbarrick

You have ip helper-address configured on R1?

mk01

No ip helper anywhere

Will give you a tip:
Is always 192.168.201.255 a broadcast address?

ande0255

Go to outbound interface on R1, "shut", problem solved.

mk01

If that was the answer, it would have 4/5 difficulty level

Dieg0M

ip-helper command forwards the broadcast as unicast, not as broadcast. Check the subnet mask is actually /24 on R1 or it will not consider 192.168.201.255 as a broadcast address and send it to default gateway.

mk01

@Dieg0M
Very close mate. There is NO subinterface for this subnet on R1. 192.168.201.0/24 is a local subnet used for vmware testing, there is even no default gateway on the host.
BTW: nice blog. Good luck with your studies!

Dieg0M

I did not talk about subinterfaces, and you did say there is a default route on R1.
"R1 forwards this message to R2 because that is the default route on R1 to send everything to R2"
Or are you saying that there is no L3 interfaces on R1 and this is strictly L2 environement?

Gngogh

Hi,

I see in the firewall log, the port 137, am i wrong?

if not, this as something to do with netbios. and i would say that you have ip directed-broadcast enable on 1 of the interfaces on R1.

Ip directed-broadcast by default forward the following UDP traffic:

Trivial File Transfer Protocol (TFTP) (port 69)
Domain Naming System (port 53)
Time service (port 37)
NetBIOS Name Server (port 137)
NetBIOS Datagram Server (port 13)
Boot Protocol (BOOTP) client and server packets (ports 67 and 6)
TACACS service (port 49)
IEN-116 Name Service (port 42)

to correct this, disable ip directed-broadcast on the interface. with the command no ip directed-broadcast.

mk01

@Dieg0M
sorry, what I meant was: there is no ip address anywhere on any network devices from this range 192.168.201.0/24. This IP exists on one host (vmware) and is trunked to a switch. A 'test' vlan, host does not even have a valid default gateway.

@Gngogh
Thank you for your message. Yes, port is related to netbios but check below. The same issue applies to icmp traffic. BTW R1 is not Cisco but it does not change anything. The idea is to identify what the issue is

R2
Deny icmp src inside:192.168.201.9 dst outside:192.168.201.255 (type 8, code 0) by access-group "inside_access_in"

Waiting for new suggestions!

Dieg0M

Ok then its probably a proxy-arp issue.

Gngogh

why does R1 forward the packets or why you computer ( vmware ) is sending packets to an address that does not exits??? why do you ping a address that does not exist???

The vmware is broadcasting that???

You want to know the source of the problem and why is happening???

I got confused now!!!!

bbarrick

Dieg0M wrote: »

Ok then its probably a proxy-arp issue.

Like an arp request from/to the virtual machine? I wonder if virtual machines even store info in an arp cache.

mk01

on R2 there is an ACL saying 'allow only 172.16.1.0, 172.16.1.5.0 etc... all KNOWN networks. That's why we can see a log on R2: Deny icmp src inside:192.168.201.9 dst outside:192.168.201.255 You are very close guys

Gngogh

I found that your icmp log, looks like a ping sweep. why are you doing that??? Icmp packets are forward by routers unless the admin block them. you are playing hacker on your vmware???

mk01

@ Gngogh

this icmp message is dropped by R2 as you can see in the logs. R2 found a route for this icmp (--->to ISP) but there is an access list saying: 'do not allow networks that you do not know about' applied on the inside interface for traffic coming in...

try and think more globally guys as it might be beyond ccna here -
why did R1 forward a packet with the destination IP that does not exist on R1 to R2?
Forget about the broadcast for a while.

bbarrick

If there is a connected route listed in R2's routing table it would naturally forward it to R2. I've heard of using a higher number mask and just using the network ID/Broadcast address as a node address but this really is beyond my knowledge at this point in time I think.

mk01

do not give up bbarrick, i will give u another example in a few minutes to explain that

Gngogh

well R1 forward, because its has a default route... the default route if is like this 0.0.0.0 0.0.0.0 int to r2, is used for unknow networks,

now R2 is very smart and is blocking networks that he doenst know about. So Vmware is not able to access anywhere outside of your Lan.

How can R2 find a route that is not routed trough the internet.

Another thing very wierd is if your ISP is real, how can it forward 192.168.201.0/24.

I cannot understand your problem, and getting really confuse when things go beyond my knowledge.

mk01

SOLUTION: The problem that I am facing is related to 'ip spoofing' (CCNA Sec topic) - it means 'pretend you are somebody else and thanks to that get access to sth you should not, perform DoS attack etc. Full solution and explanation is beyond CCNA but is not difficult and popular security issue in the real world. As a CCNA engineer you might be required just to recognize that this is suspicious e.g. in the logs and escalate it.

Normally when your router receives IP packets it only cares about this: What is the destination IP address of this IP packet so I can forward it?

To answer your question, which is very good:
Another thing very wierd is if your ISP is real, how can it forward 192.168.201.0/24.

Well - that is YOUR job to make sure a priv network does not go to your ISP. Again - router is just a router, it does not care what the SOURCE IP is, if it finds a route - it sends it!

bobfromfpl

It might just be me.. but I dont see how your example solution shows what you described in the original problem.

Dieg0M

First of all, this is a security problem and not a routing and switching problem. Also, you said you have this problem in a real environment. How do you have IP spoofing in a real environment, do you have a security breach? Third, it is NOT your job to make sure a priv network does not go to your ISP. Private networks are NOT routed through the internet, only public addresses are.

What are you trying to teach here, IP spoofing in a CCNA lab? This was a complete waste of time.

mk01

There are a lot of solutions for problems like that, it all depends what device you have. In my firewall I enabled "Spoof Prevention" under Firewall options. With this, if the firewall receives any request from a foreign IP, for which it doesn't have a reverse route, the same would be dropped.

mk01

Dieg0M wrote: »

First of all, this is a security problem and not a routing and switching problem. Also, you said you have this problem in a real environment. How do you have IP spoofing in a real environment, do you have a security breach? Third, it is NOT your job to make sure a priv network does not go to your ISP. Private networks are NOT routed through the internet, only public addresses are. This company learnt it in a hard way!

What are you trying to teach here, IP spoofing in a CCNA lab? This was a complete waste of time.

Well... I can tell you this:
2 years ago I received a phone call from a client, who said that ISP blocked their Internet connection. Do you know why? Because the firewall had NAT broken for some networks and a ISP router was flooded with private source IPs which this router of course had to drop. It was a big network, they called someone to discuss but it was ignored by the Service Desk. So yes - it is your job to make sure that private networks do not go to your ISPs and that is the main focus in my video for this lab/scenario really but I made a challenge for it.

The idea of this challenge was not to teach all about ip snooping, it is to show a real life scenario and how to deal with it from the ROUTING PERSPECTIVE. It is not on a Cisco device to make it easier to understand. Unfortunately Cisco decided to teach Frame Relay in CCNA and not ip snooping...

But you are right, maybe I should have posted it in CCNA Sec section. My project is about CCNA and CCNA Sec as well!

You are CCNP so you know what people expect you to do. Did you have to implement VRFs? Well... they are NOT in CCNP and in my previous company CCNA guys were required to learn it!

Third question: Yes, it is a production environment, Microsoft guys deployed a vmware server and started to flood the network with rouge IPs, broadcasts etc.

That's why it was called a challenge mate

Thanks Dieg0M for your comments as well and I keep your fingers crossed for your CCIE mate, it is great you have a blog, will follow it mate!

Dieg0M

1. Private addresses are not routable through the internet. You don't know what you are talking about. If you were sharing BGP routes with your ISP, you would have a strict prefix-list filtering on both sides.
2. uRPF is taught in CCIE lessons, the reason they decided to teach frame-relay in the CCNA is because the concept of an NBMA network is much more important to understand than IP spoofing for a CCNA candidate
3. IP spoofing is not something that is done by accident. How would that even pass a CCB review?

If you want to make CCNA labs or challenges, at least make it about something that a CCNA candidate will see in their studies. After reading this, I would NOT want to invest a penny in your project. I really believed you were gonna come up with something tricky as a solution. You truly disappointed me, but what would you expect from someone who typo's in his "challange"?

mk01

You are upset because you did not figure it out, but it is ok. Just kidding

Relax a little here. It might be just enough to move it to CCNA Sec section if this is for beginners only. And yes - i made a spelling mistake and cannot fix it as i cannot edit topics. I mentioned this challenge requires skills beyond ccna...

I would like to finish this discussion as it is not related to the topic. Just a link to answer your first question as not sure what bgp has to do with egress rules...
http://securityskeptic.typepad.com/the-security-skeptic/firewall-best-practices-egress-traffic-filtering.html
that's what I meant.

Good luck and thank you for your comments. Believe it or not - it is useful all very useful for me and makes me think about topics I cover and want to show.

Dieg0M

Let me ask you this, is IP spoofing really the root cause of this issue? Would you have this problem if you had no default route and only exact match prefixes?

mk01

Thank you Dieg0M, that was a good point!

Of course I did not have time to investigate all options but enabling 'Spoof protection' sorted it out. What else were you thinking of?

BTW I sent you a priv message, did u get it? its not in my sent items. We can continue this discussion in that way, will be easier?

Thanks!