RFC 1918 Traffic leaving the WAN interface

[IsaacFL]

@chpalmer said in RFC 1918 Traffic leaving the WAN interface:

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

RFC explicitly says not to do that.

Yes. And your ISP handles that for you.

You will not find a single SOHO router that blocks out of subnet traffic from going out the gateway.

What is borked is a device that is trying to reach an RFC 1918 that is not in your network somewhere. Id be wanting to fix that and not be trying to band-aid the problem.

I am not suggesting that pfSense should do that by default. It just seems to me that in my case, just having a default route to drop all undefined RFC 1918 traffic can be done in one place with one static route.

I can't think of any downside?

[johnpoz]

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

I can't think of any downside?

Not being able to see what is doing it... because if something is doing it, then there is something wrong..

Do what you want.. I would never do it that way when it takes all of 2 seconds to create a firewall rule to do exactly what you want... And now you have control and visibility of exactly what is happening..

Another downside of routing to nowhere, with a firewall rule I can send a reject telling the client hey you can not freaking get there!!! Now it doesn't have to wait for timeout, now it would be sending retrans, etc..

[chpalmer]

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

I can't think of any downside?

^^ what Johnpoz said ^^ +1

Good luck!

[IsaacFL]

@johnpoz said in RFC 1918 Traffic leaving the WAN interface:

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

I can't think of any downside?

Not being able to see what is doing it... because if something is doing it, then there is something wrong..

Do what you want.. I would never do it that way when it takes all of 2 seconds to create a firewall rule to do exactly what you want... And now you have control and visibility of exactly what is happening..

Another downside of routing to nowhere, with a firewall rule I can send a reject telling the client hey you can not freaking get there!!! Now it doesn't have to wait for timeout, now it would be sending retrans, etc..

I am still logging it with a firewall rule. I log all local traffic.

[IsaacFL]

@johnpoz said in RFC 1918 Traffic leaving the WAN interface:

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

I can't think of any downside?

Not being able to see what is doing it... because if something is doing it, then there is something wrong..

Do what you want.. I would never do it that way when it takes all of 2 seconds to create a firewall rule to do exactly what you want... And now you have control and visibility of exactly what is happening..

Another downside of routing to nowhere, with a firewall rule I can send a reject telling the client hey you can not freaking get there!!! Now it doesn't have to wait for timeout, now it would be sending retrans, etc..

I guess I can send a bug report to Apple and see what their response is. I think it is something to do with HomeKit or Airplay since I am seeing that other people have seen the same thing I am seeing.

I am already rejecting the traffic and it still keeps trying.

[JKnott]

@chpalmer said in RFC 1918 Traffic leaving the WAN interface:

What is borked is a device that is trying to reach an RFC 1918 that is not in your network somewhere.

How would a device know an address wasn't used by you somewhere? The only thing it can do is tell the address is not on it's local LAN and has to be sent to the router.

[JKnott]

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

If my ISP was using RFC 1918 address space, then when PfSense received the DHCP address wouldn't it would create a default route to the gateway address provided by the ISP even if it was RFC1918?

Yep. That's another example of why you can't just keep those addresses from being routed.

[johnpoz]

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

I guess I can send a bug report to Apple and see what their response is

You know for a fact its your iphone device? I see some talk of airplay looking for shit on 7000.

You already sniffed it, did you open it in wireshark to see what it might be looking for if its airplay traffic.

Maybe something like

GET /info RTSP/1.0
X-Apple-ProtocolVersion: 1
Content-Length: 70
Content-Type: application/x-apple-binary-plist
CSeq: 0
DACP-ID: 70658D74F8C202C9
Active-Remote: 882070098
User-Agent: AirPlay/383.4.3 

[IsaacFL]

@johnpoz Yeah, I have verified that every iOS (I don't have any macs) device I have does it periodically.

The Apple TVs (I have 2) are most by volume.

I have also have 3 iPhones and 2 iPads that I have also logged instances of it happening but I haven't been able to figure out a series of actions that trigger it.

[IsaacFL]

What I have done in the mean time, is disabled my static route to null, since I am being advised against that.

I have created an alias "Private_Networks" with values of "192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, fc00::/7 " (I added ipv6 ULAs too).

I then created a Floating Rule to reject the Private Networks Out of the WAN

This is working, but for logging it is not so great as the source address is always my WAN ipv4 address..

[chpalmer]

@JKnott said in RFC 1918 Traffic leaving the WAN interface:

How would a device know an address wasn't used by you somewhere? The only thing it can do is tell the address is not on it's local LAN and has to be sent to the router.

Right. to a point. The only thing it can do is tell the address is not on it's local LAN and has to be sent to the router.

Anything else should be outside of RFC 1918! Period. No reason to do otherwise unless directed by you. Nothing in RFC 1918 should be hard coded.

Change my mind.

[johnpoz]

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

This is working, but for logging

Thats why you do it on the lan side interface.. Also not sure what good rejecting on the outbound direction does?

Nothing in RFC 1918 should be hard coded.

Nothing in public space should be hard coded either.. You need to get to something you should look it up via its fqdn

[IsaacFL]

@johnpoz said in RFC 1918 Traffic leaving the WAN interface:

Thats why you do it on the lan side interface.. Also not sure what good rejecting on the outbound direction does?

If I put it on the LAN interface then it also blocks access to the other subnets since I am using RFC1918 addresses as my local IPv4 addresses.

[IsaacFL]

@johnpoz I did put a reject rule on the subnet with the iphones, etc. So the WAN rule is there in case another subnet acts up.

[johnpoz]

@IsaacFL said in RFC 1918 Traffic leaving the WAN interface:

If I put it on the LAN interface then it also blocks access to the other subnets since I am using RFC1918 addresses as my local IPv4 addresses.

How many times do we have to go over the same thing? What exactly do you not understand about how rules are processed? Top down, first rule to trigger wins, no other rules are evaluated..

Allow what traffic you want to your other vlans, then block to all rfc1918, allow to internet.. You have even been given examples..

edit: Here is yet another example... So I created an alias with my Local networks in it... I have an alias that has all of rfc1918 space int it... I allow to my local nets, then block to any rfc1918, then allow internet

Now anything going to my local networks from lan is allowed, anything going somewhere some odd ball rfc1918 is blocked and logged.

[IsaacFL]

@johnpoz Ok, I think I got it now. My only issue was I want to log the local traffic, but not external traffic.

So for my LAN which is allowed local traffic:

The LAN net to LAN net was so that I don't log the broadcast, etc.

On my IOT interface which is restricted to external:

This seems to be working and is logging what I want.

[chpalmer]

What have you done to get multicast to work? Or is it?

[IsaacFL]

@chpalmer said in RFC 1918 Traffic leaving the WAN interface:

What have you done to get multicast to work? Or is it?

The multicast rule is because I have enabled Avahi for mDNS. mDNS uses multicast and this rule allows ipv6 multicast into the router so Avahi works.

There isn't a default rule to allow traffic from ipv6 link local to multicast and without this rule only ipv4 mDNS works.

I wrote a general rule that works for both ipv4 and ipv6 in case I want to log it. My Multicast Alias is ff00::/8, 224.0.0.0/4

But generally multicast between subnets does not work, as pfSense does not have a module to route it to the other subnets. At least that I know of.

[chpalmer]

This is why I asked.. https://forum.netgate.com/topic/139218/sonos-speakers-and-applications-on-different-subnets-vlan-s

[IsaacFL]

Yeah, this is the package which would maybe work. I have never tried to install it so I group all of these type of devices in one subnet.

I mostly have been working on ipv6 and I can say I am not sure that even with that package it would work across subnets at least for ios devices.

I have noticed that ios devices, instead of advertising their ipv6 global address, they advertise their link local address only via mDNS. So even if you had the pimd package installed, I don't think it would work, since link local addresses can't cross subnets.