Ethernet Switching
Highlighted
Ethernet Switching

Layer 3 irb issues

‎10-12-2018 11:48 AM

Hi all,

When an irb.10 is setup lets say with subnet 10.10.0.0/24 and I setup manually on my pc an ip address 100.195.0.10.
Port where my pc is connected to is setup as access and member of vlan 10.
I send a packet with a destination which belongs to another irb.20 ( 10.20.0/24 ) of the same switch packets will pass through and there is inter vlan
comminication.
This can be prevented with an ingress access list but this can not prevent the internal attacker to setup another public ip adddress manually and
bombard my system with tcp packets and cause a DOS attack.

IP Source Guard is not available but by the time the source ip address does not belong to the same broardcast domain with my irb then this traffic should be blocked by default I think and not be routed through L3 engine of the switch and allow inter vlan communication.  

 

Any ideas ?

5 REPLIES 5
Highlighted
Ethernet Switching

Re: Layer 3 irb issues

‎10-12-2018 12:13 PM

Sorry, your message makes no sense to me.  What is the L3 address for irb.10?  I assume something like 10.10.0.1, yes, for subnet 10.10.0.x/24?  How can that route a packet from a different subnet, like from a host with address 100.195.0.10?  What is def GW for the host to start with?

 

 

Highlighted
Ethernet Switching

Re: Layer 3 irb issues

‎10-12-2018 12:39 PM

Well it doesnt make sense to me also what is happening. 
Yes L3 irb.10 is the default gateway for my subnet with ip address  10.10.0.1. It is where packets arrive in order to be routed to another subnet via the Layer 3 engine and the routing table of the L3 switch. 
About what is the default gateway of ip address 100.195.0.10 this is someting I do not know as I captured packets via wireshark on my server where these requests arrive to. 
The source is a ChromeOS machine and this is from where these packets come from. 

There is an issue with ChromeOS boxes and this is a bridged adapter (  br0)  with this ip address 100.115.92.1 and sends packets to my server. 
The question now is how this packet passed the default gateway of vlan 10 in this case irb.10 and was routed to another subnet ( irb.20 ) and arrived to the private ip address of my server.
I can understand that the destination ip address was the private ip address of my server BUT source ip address was not evaluated at all in this case which I think is a disaster. 
This doesnt make sense at all form a routing perspective to pass packets though from an irb to another one since the source ip address does not belong to either of them.

I hope things are more clear now for you !
Thank you for your fast reply Smiley Happy

Highlighted
Ethernet Switching

Re: Layer 3 irb issues

‎10-12-2018 10:54 PM

Hello,

 


@nikostsironis wrote:


The source is a ChromeOS machine and this is from where these packets come from. 

There is an issue with ChromeOS boxes and this is a bridged adapter (  br0)  with this ip address 100.115.92.1 and sends packets to my server. 
The question now is how this packet passed the default gateway of vlan 10 in this case irb.10 and was routed to another subnet ( irb.20 ) and arrived to the private ip address of my server.

 

Well, then You need to ask ChromeOS developers how their kit dynamically discovers the MAC address of DGW of a subnet that is not configured on ChromeOS box. Or maybe the ChromeOS box sends unicast IP packets encapsulated as broadcast/multicast Ethernet frame. The proper capture should tell.

As to "why such packet passes DGW" - this is default behaviour for the network elements that do routing. Any valid unicast IP packet, if it arrives in Ethernet frame whose dst.MAC==DGW' MAC will get routed assuming a valid route to destination exists.  

 


@nikostsironis wrote:


This doesnt make sense at all form a routing perspective to pass packets though from an irb to another one since the source ip address does not belong to either of them.

 


 As I mentioned, "passing [valid IP] packets [without checking the src.IP] through" is the default behaviour for the box that does routing. If You want to prevent this from happening, either use an IP Src guard or unicast RPF

 https://www.juniper.net/documentation/en_US/junos/topics/concept/unicast-rpf-ex-series.html

HTH

Thx
Alex

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Ethernet Switching

Re: Layer 3 irb issues

‎10-13-2018 12:12 AM

 

Highlighted
Ethernet Switching

Re: Layer 3 irb issues

‎10-13-2018 01:23 AM

I agree with @aarseniev assessment.  The someone could likely be Chrome OS as Unix machines can do this as well.  Someone/something is routing to irb.10 not as Def GW, but as standard routing and irb.10 knows how to route to irb.20 as both are local.

 

I might suggest you look at this backward.  Assume switch (EX3400?) is working as expected, and look elsewhere for the source of the situation.

 

BTW, if indeed this an EX3400, IP Source Guard support was added in 18.2R1:

 

https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching&typ=1#family=&pid=...

 

Good luck.