RFC 1918 Traffic leaving the WAN interface

[johnpoz]

^ yup very true - unless creates a rule to allow that access above... Again null route sort of solution not a good one.

example

Something like the above would stop what your seeing, and if you set the rule to LOG - then you would see if anything is trying to go to some rfc1918 space.. And you would see what specific client is doing it, and exactly when.. Since it would be in your logs... And simple view of the rules would tell you if any hits on it to go look in the logs via 0/X number increasing..

edit:
example 2

See the rule blocking access to rfc1918, and being logged - this is how I could show you stuff being blocking going to my plex IP on the plex port (out of state)..

[chpalmer]

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

I read that too quickly I guess

I refuse to comment on the grounds it may tend to incriminate me..

[IsaacFL]

@johnpoz

Ok, so I deleted my route, and created a RFC 1918 reject rule on the subnet with the Apple devices. It seems to log every few minutes. Weird thing is it is not even in the same /24. Googling tells me port 7000 is related to Airplay.

the .230 and .231 are both Apple Tv's but I have also seen it on the iphones.

[IsaacFL]

The problem with blocking the RFC 1918 traffic is that now all local traffic is getting blocked also, which is fine on an IOT network.

Probably this would require a floating rule on the WAN network.

What is the problem with adding the null route I had before? This seems to me more of a routing problem vs a firewall problem.

[Pippin]

Do your neighbours have Apple products?
https://www.reddit.com/r/HomeKit/comments/bk1ee9/home_app_tries_to_communicate_with_random_ip_on/

[IsaacFL]

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

Do your neighbours have Apple products?
https://www.reddit.com/r/HomeKit/comments/bk1ee9/home_app_tries_to_communicate_with_random_ip_on/

I don't know for sure but they probably do. That was my concern is that there might be an actual device outside my network.

[johnpoz]

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

The problem with blocking the RFC 1918 traffic is that now all local traffic is getting blocked also

What the F you think could happen with your nonsense routing stuff to null?

If you want vlan on 192.168.X to talk to another vlan 192.168.Y for example - then allow that traffic above your block rule.. As shown in my example I allow to talk to my plex server on a different rfc1918 vlan.. I allow devices to talk to my ntp that is on another rfc1918 vlan. Just allow what rfc1918 traffic you want to allow before you block..

If you want lan to talk to your dmz net for example, then put that rule above where you block rfc1918.

Rules are evaluated, top down, first rule to trigger wins..

If all you have is 1 network, there is no other vlans to talk to using rfc1918.. Devices on your network don't talk to pfsense to talk to something on their own network.

[IsaacFL]

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

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

The problem with blocking the RFC 1918 traffic is that now all local traffic is getting blocked also

What the F you think could happen with your nonsense routing stuff to null?

If you want vlan on 192.168.X to talk to another vlan 192.168.Y for example - then allow that traffic above your block rule.. As shown in my example I allow to talk to my plex server on a different rfc1918 vlan.. I allow devices to talk to my ntp that is on another rfc1918 vlan. Just allow what rfc1918 traffic you want to allow before you block..

If you want lan to talk to your dmz net for example, then put that rule above where you block rfc1918.

Rules are evaluated, top down, first rule to trigger wins..

If all you have is 1 network, there is no other vlans to talk to using rfc1918.. Devices on your network don't talk to pfsense to talk to something on their own network.

I think it is just as much nonsense to route it out the WAN interface when the RFC explicitly says not to do that.

I have much more than 1 subnet.

When you route to null, the router just drops the packet.

So if I create a static route for 10.0.0.0/8 to Null4 - 127.0.0.1 and pfSense has already auto created routes for each defined interface ie. 10.23.30.1/24 etc.

The router knows to always pick the most explicit route.

But I am willing to hear why that might be an issue that I don't understand?

[JKnott]

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

I think it is just as much nonsense to route it out the WAN interface when the RFC explicitly says not to do that.

Those addresses are just as routeable as any other. What if the WAN side was also in RFC 1918 address space? They should be blocked from the Internet though, which can be done with appropriate filters.

[chpalmer]

@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.

[IsaacFL]

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

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

I think it is just as much nonsense to route it out the WAN interface when the RFC explicitly says not to do that.

Those addresses are just as routeable as any other. What if the WAN side was also in RFC 1918 address space? They should be blocked from the Internet though, which can be done with appropriate filters.

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?

[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.