how to block return traffic?

ler762

@johnpoz Can we please get past the question of does what I want to do make sense to you?

I bought a firewall because I wanted a central place to implement my security policy. One of the items in that policy is to block all traffic coming from the Internet that has a 10 network address.

Is that possible with a netgate sg-3100 firewall?

johnpoz

@ler762 said in how to block return traffic?:

Is that possible with a netgate sg-3100 firewall?

To do what? You seem not to understand basic concepts..

You want to allow traffic, and then block the answer? What firewall does that - that is not how stateful firewalls are designed to function..

Go back to the old days of non stateful firewalls and just packet filters - then sure you can do what you are asking.. But again for why because you don't grasp the concept of your isp using rfc1918 in their network?

You understand that answer that says 10.x is a icmp reply to your ping request from the TTL being expired.. Just at a complete an utter loss why you think this needs to be blocked from giving the answer to the client that asked to do something..

Here is the hop where I get back 10 in my isp.. See I requested a ping to 8.8.8.8, and the hop in the isp network where the ttl expired is telling me that..

When you do that pfsense keeps track of that..

He is allowing the answer to what you already allowed to ask.. If you don't want the reply - then don't let it out in the first place.

mer

@ler762
With a sg-3100, with WAN connected directly to the Internet, if your provider hands you out a non RFC-1918 address you can block out unsolicited traffic if it originated/started by a 10.x.x.x address.
Notice the couple of condition there:
Your upstream hands out a real world IP to your WAN.
The traffic flow is started by "outside" and initially hits your WAN.

Some providers hand out RFC-1918 addresses, so they could hand out a 10.x.x.x to your WAN. If you block that, you can't do anything.

The second part is the traffic needs to start from outside, otherwise it has state and replies to the flow are allowed back in.

So your traceroute is from:
client pc to opt1 to router to ISP to "internet"

The router connected to the ISP link, what addresses does it have?
Are you positive that the ISP is not using 10.x.x.x addresses on their network? It would be perfectly fine for them on their internal network, especially for routers. I would also consider "your network" to be part the ISP network, at least up to your router.

Stateful firewalls, all of them, block arbitrary traffic if there is no state for the flow. State for a flow is started by the initial outbound traffic.

You telephone: someone dials the number and you don't answer. That is traffic that originated from outside and was blocked because you don't have any state.

You dial a number from your phone, other end answers and says hello. That hello is not blocked because you established state by originating the call.

traceroute is probably not the best way to test what I think you are trying to test on any stateful firewall.
Why? Because by definition, return packets from all routers between "here and there" are part of the flow, because the flow originated "here" which causes state.

TCP/RST DOS. If that is the first packet seen in a flow and originates from outside, the default deny rule on WAN will block it and cause the packet to be dropped.
That is the way the default deny rules work. A better description would be (to me):
default deny in on an interface if there is no existing state

the pf rule is something like:
block drop in on WAN

What you sound like you are trying to do is:
drop packets in on WAN if they originate from 10.x.x.x even if they are return packets for a flow originating from me.

You would need to ensure that everything from your "WAN" port of your router connected to the ISP uplink and everything internal to the ISP before it goes out to the world is not using a 10.x.x.x address.

SteveITS

@mer said in how to block return traffic?:

other end answers and says hello. That hello is not blocked because you established state by originating the call

I thought I'd link to the doc page on this for the OP.

Put another way, the way to prevent the reply is to block the outgoing connection (firewall rule on LAN).

mer

@steveits Good stuff. Thanks.

johnpoz

He could possible do some odd NONE state settings.. And turn it into an old school packet filter..

But again - WHY.. He has gone down this rabbit hole because of lack of actually understanding what is happening.

A reply from a 10 address on his isp network via a icmp notification when the ttl expired is normal, why would you block that.. Then all you would see is nothing for that hop at all - just pointless..

how is something like this better or more secure?

 13   206 ms   194 ms   205 ms  202.97.57.146
 14     *        *        *     Request timed out.
 15   219 ms   219 ms   204 ms  218.4.208.210

Unsolicited inbound traffic is not allowed, be it comes from rfc1918 or public.. Unless he specifically allows for it.. Answers to something you requested is allowed via the state.. Seeing a rfc1918 address in a trace is nothing to get worried about.. It happens all the time - many isp use rfc1918 inside their network. And it could be just that hop is answering via its loopback, etc.

My first hop into the isp network, is not the IP of my gateway either.. Its what that hop answered with for the icmp ttl expired notification, doesn't mean it was the IP the traffic was sent to, doesn't mean its the IP of the transit network between the routers. Without knowing the details of the config of that router. You can not be sure what IP might be used as source in the icmp notification of your ttl having expired. Pretty much any router on the internet or in your isp network or really anywhere is going to have more than 1 or 2 IPs.. What it uses as the source for icmp notification is not always the same as the IP the traffic was sent to via routing. And even if it is - there is nothing saying a ISP can not use rfc1918 as their transit networks between routers.

mer

@johnpoz I agree. I feel we are missing information and we have a fundamenal misunderstanding of want/possible/makes sense.

johnpoz

Here you go - this topic is perfect for this discussion and seeing a IP in the trace you do not understand

https://blog.ine.com/2013/09/06/modifying-traceroute-replies

ler762

@mer

I feel we are missing information and we have a fundamenal misunderstanding of want/possible/makes sense.

I agree. Clearly I haven't been doing a very good job of communicating, so let's keep it real simple.

Want: to be able to block any traffic going through the firewall. I don't care if it's part of a stateful flow or no, if I think it should be blocked I want to be able to block it.

Possible? apparently not with a netgate :(

Makes sense? see the Security considerations section in
https://www.ietf.org/rfc/rfc1191.txt

In the first attack, the false message indicates a PMTU much smaller
than reality. This should not entirely stop data flow, since the
victim host should never set its PMTU estimate below the absolute
minimum, but at 8 octets of IP data per datagram, progress could be
slow.

https://www.ietf.org/rfc/rfc5927.txt

ICMP Attacks against TCP

https://www.ietf.org/rfc/rfc4890.txt

Recommendations for Filtering ICMPv6 Messages in Firewalls

Is that enough of a justification to answer your "makes sense" question?

johnpoz

@ler762 said in how to block return traffic?:

Want: to be able to block any traffic going through the firewall.

You do that before it "enters" the firewall.. Not return traffic from traffic you already allowed!

As stated already... If you do not want to allow icmp, then block it! You allowed the icmp traceroute.. So the icmp reply to your own traffic is allowed by the STATE!

Simple rule on you LAN block icmp - there you go

There is no freaking way you read that rfc5927, and think what you have posted has anything at all to do with your traceroute example... And the mitigations to such attacks have ZERO to do with what you have tried

If your concern is mitigation of specific type(s) of attack gone over in a rfc, or elsewhere and if pfsense can or already does or what can or can not be done to mitigate such types of attacks. A better post specifically that question.. A reply from a 10 address in a traceroute is not an "attack" that needs to be mitigated ;)

If what you want is the ability to filter specific types of replies to something you allowed to be asked for.. Yeah I am not aware of that "feature" in pfsense.

Allow connection to any IP port X (syn)
Block the syn,ack if it comes from IP A, or network B..

Not aware of such a feature.. You could maybe do such a thing with some fancy rules not creating states. The simple solution is not allow the syn to even go to IP A or network B in the first place - this stops the traffic from "going through" the firewall.

But if your concern is actually can pfsense mitigate xyz attack, if so how or is it being done already would be much cleaner and better way to ask this question.