how to block return traffic?
-
I'm guessing that whatever is allowing return traffic is over-riding my firewall rules. How do I make my rules take precedence?
My WAN firewall rules start off with deny ipv4 source 10.0.0.0/8 but I get a traceroute answer from a 10 network address :(
How do I block this?
.. and related, how can I block TCP RSTs coming in from the Internet?
-
on the interfaces tab, the WAN interface, near the bottom should be a section labelled something like "reserved addresses" with 2 check boxes.
If your WAN is getting a public IP from it's upstream, check both boxes and then apply and remove your first rule, save and apply.
Remove your first rule save and apply.I believe pfSense automatically creates antispoof rules for you for the interfaces that you configure and enable.
Now as to your question:
There is a difference in where the traffic originates: externally or internally.
I'm assuming your traceroute command is actually being done on either the pfSense box itself or a system behind it. If that is correct, then that outbound traffic is generating a state in the firewall so any responses from outside are processed.
If the traffic originates outside, then pfSense has no state for it and it would get dropped. -
@mer said in how to block return traffic?:
I believe pfSense automatically creates antispoof rules
Not for me.
I should have said the traceroute was from a machine on the OPT1 subnet originally -- sorry.
I changing my OPT1 address to 10.252.242.1, added a "permit any any" firewall rule as the 1st rule on OPT1 & tried the traceroute again:
$ ip a
...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:1f:16:76:7d:cb brd ff:ff:ff:ff:ff:ff
inet 10.252.242.60/24 brd 10.252.242.255 scope global noprefixroute enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::6d81:57ba:cfe6:866a/64 scope link noprefixroute
valid_lft forever preferred_lft forever$ traceroute 216.239.36.10
...
8 10.252.212.62 (10.252.212.62) 20.087 ms 10.252.242.190 (10.252.242.190) 8.574 ms 10.252.64.190 (10.252.64.190) 8.757 msOhNoes!!! 10.252.242.190 is MY subnet
No anti-spoofing here :(
And the first rule on the WAN interface is still deny ipv4 source 10.0.0.0/8 to any .. that clearly isn't effective :(How do I set firewall rules that take precedence over anything else like the permit return traffic automatic rules?
-
@ler762 I think you are misunderstanding how a stateful firewall works..
If you create a connection to somewhere, then a YES the returned traffic would be allowed. If you do not what return traffic from somewhere, then prevent the initial connection to that somewhere in the first place.
Those rules on the wan are meaningless.. When could source traffic from your LAN net EVER be source traffic into your WAN?
Traffic is evaluated as it enters the interface from the network attached to the interface - it would not be possible for LAN net or OPT1 net to be source of inbound traffic to the WAN..
BTW - default is DENY anyway.. If there is not a allow rule, then traffic would not be allowed. Wan defaults to having a block source of rfc1918 on the wan as well.. So you must of turned that off.. By default bogon and rfc1918 as source is blocked on the wan.
how can I block TCP RSTs coming in from the Internet?
Huh? If you try to talk to something, and it sends you a RST - then he doesn't want to talk to you or wants to close the session NOW.. Just at a complete lost to what you think "blocking" them would accomplish.
If out of state traffic is sent to pfsense on any interface it would be denied by default and dropped anyway. Only a SYN can open a state, a RST or a ACK or RA or a SA or FIN or FA, will just be dropped if there is not already a state to allow the traffic.
As to your traceroute showing rfc1918 in it - that could very well be your isp network.. A device along your route can answer with any IP it wants, it really doesn't have to be public.. Here same thing happens on my isp network..
See the 10 in there
$ tracert -d 8.8.8.8 Tracing route to 8.8.8.8 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.9.253 2 10 ms 18 ms 10 ms 50.4.135.1 3 8 ms 8 ms 10 ms 10.52.33.194 4 11 ms 11 ms 13 ms 76.73.164.154 5 11 ms 11 ms 12 ms 75.76.101.196 ^CTo the antispoofing comment - those rules are there by default, just not shown in the gui
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html#viewing-the-pf-ruleset
[21.05.1-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep spoof antispoof for $WAN tracker 1000001570 antispoof for $LAN tracker 1000002620 antispoof for $WLAN tracker 1000003670 antispoof for $TEST tracker 1000004720 antispoof for $NS1VPN tracker 1000005770 antispoof for $W_PSK tracker 1000006820 antispoof for $W_GUEST tracker 1000007870 antispoof for $W_ROKU tracker 1000008920 antispoof for $DMZ tracker 1000009970 [21.05.1-RELEASE][admin@sg4860.local.lan]/root:https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#anti-spoofing-rules
-
@johnpoz said in how to block return traffic?:
I think you are misunderstanding how a stateful firewall works..
If you want to make the argument that I don't understand how a netgate firewall works.. then yes. I'm hoping that it can do better than just stateful filtering.
If you create a connection to somewhere, then a YES the returned traffic would be allowed. If you do not what return traffic from somewhere, then prevent the initial connection to that somewhere in the first place.
How do I do that in this case?
My security policy includes these rules
- internal users can do a traceroute.
- "internal" source addresses are not allowed in from the Internet
I've got a 10.252.242.0/24 internal subnet. Someone on that subnet does a traceroute ... and gets an answer from a 10.252.242.0/24 address.
Aside from not allowing traceroute, what rule can I put in place to block answers coming in from the Internet from 10.252.242.0/24?
Traffic is evaluated as it enters the interface from the network attached to the interface - it would not be possible for LAN net or OPT1 net to be source of inbound traffic to the WAN..
I just gave you an example of exactly that. A packet with an IP source address of 10.252.242.190 came in from the Internet.
Or your example.. traceroute to a google nameserver and get an answer from 10.52.33.194BTW - default is DENY anyway.. If there is not a allow rule, then traffic would not be allowed. Wan defaults to having a block source of rfc1918 on the wan as well.. So you must of turned that off..
Yup. Eventually I want to have the netgate directly attached to the Internet, but it's still "inside" and using an RFC-1918 address on the WAN interface. So I can't put a checkmark for blocking RFC-198 addresses yet.
how can I block TCP RSTs coming in from the Internet?
Huh? If you try to talk to something, and it sends you a RST - then he doesn't want to talk to you or wants to close the session NOW.. Just at a complete lost to what you think "blocking" them would accomplish.
it would block a denial of service attack - eg
https://en.wikipedia.org/wiki/TCP_reset_attackOr pick any other denial of service attack that would make it through a stateful firewall - sending an ICMP unreachable, redirect, packet too big, whatever.
The question isn't if what I want to do makes sense to you, the question is can I block it?
As to your traceroute showing rfc1918 in it - that could very well be your isp network.. A device along your route can answer with any IP it wants, it really doesn't have to be public..
I understand that. I don't care who is doing it, I just want to be able to block it.
Here same thing happens on my isp network..
so you've got the anti-spoofing rules turned off also?
To the antispoofing comment - those rules are there by default, just not shown in the gui
except the antispoofing functionality clearly isn't working for me.
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html#viewing-the-pf-ruleset
https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#anti-spoofing-rulesThanks for the links -- I'll take a look.
-
@johnpoz "If you create a connection to somewhere, then a YES the returned traffic would be allowed. If you do not what return traffic from somewhere, then prevent the initial connection to that somewhere in the first place."
That is where the floating rules come in, no? I'm referring to the second sentence here.@ler762 "I've got a 10.252.242.0/24 internal subnet. Someone on that subnet does a traceroute ... and gets an answer from a 10.252.242.0/24 address."
Does traceroute not work by setting TTL, then routers go and forward the packets, hop by hop? That would indicate to me something on your 10.252.242.0/24 network is a next hop for the packets on the way out.
The client on OPT1 eventually hits OPT1 on pfSense, so isn't pfSense a hop in the route and it answers?The following statement implies to me that the packet you don't want is coming from one of your upstream of the WAN assets that is a next hop in the route as a return to an outbound packet keeping state.
"Yup. Eventually I want to have the netgate directly attached to the Internet, but it's still "inside" and using an RFC-1918 address on the WAN interface. So I can't put a checkmark for blocking RFC-198 addresses yet."
I don't know if there is a way to set up rules that "keep state unless I don't want it to".
-
@ler762 said in how to block return traffic?:
I understand that. I don't care who is doing it, I just want to be able to block it.
Blocking WHAT? A rfc1918 address in your traceroute? Makes zero sense - your ISP has a rf1918 address in their network - so what??
So I can't put a checkmark for blocking RFC-198 addresses yet."
Why not? The block rfc1918 is inbound traffic to your wan from a source IP.. You show no port forwards.. etc..
What exactly are you having an issue with - I can not see what your trying to accomplish that makes any sense. Other than a rfc1918 in your trace is confusing you?
The block rfc1918 default rule - blocks inbound unsolicited traffic from the wan side/ internet to your wan IP.. This has nothing to do with some hop in the isp network reporting back a rfc1918 address. Nor does it have anything to do if you are going to run pfsense behind a double nat..
-
@johnpoz said in how to block return traffic?:
https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#anti-spoofing-rules
"... Anything initiated on the internal network with a source IP address that does not reside on the internal network is dropped."
doesn't work for me.
I changed my opt1 interface address to 10.10.6.1
If I put a deny !opt1 net firewall rule on the opt1 interface spoofed traffic is blocked.
If I put a permit any any rule on the opt1 interface spoofed traffic is allowed.
this is what I ran on my laptop connected to the OPT1 port to switch from the DHCP assigned opt1 network address to a spoofed address:
$ cat set.net10
#!/bin/shsudo ifconfig enp1s0 10.252.242.60 netmask 255.0.0.0
sudo route add -net 10.0.0.0/8 gw 10.252.242.60
sudo route add -net 10.10.2.0/24 gw 10.10.6.1
sudo route add -net 0.0.0.0/0 gw 10.10.6.1 -
@mer What do you get if you do a traceroute to 8.8.8.8 or 216.239.38.10? (on windows it'd be 'tracert -d')
If one on the hops is a 10 network address you can play along at home -- try to block anything with a source address of 10.0.0.0/8 coming in from the Internet. I haven't been able to yet & floating rules don't do it (at least for me)
... isn't pfSense a hop in the route and it answers?
Yup, very first hop.
Originally I had the opt1 interface set to 10.10.6.1
I was working on something else and noticed that a traceroute came back with a 10.252.242.60 address on one of the hops. To make the point that the anti-spoofing rules aren't working for me I changed the OPT1 interface address to 10.252.242.1 and re-ran the traceroute.The first hop was the netgate opt1 interface address, then the router I have connected to the ISP link, and a few more hops until
8 10.252.212.62 (10.252.212.62) 20.087 ms 10.252.242.190 (10.252.242.190) 8.574 ms 10.252.64.190 (10.252.64.190) 8.757 ms10.252.212.62
10.252.242.190
10.252.64.190
don't exist anywhere on [in?] my network.I don't know if there is a way to set up rules that "keep state unless I don't want it to".
I want to be able to block arbitrary traffic. I'm beginning to think a netgate firewall can't do that :(
-
@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?
-
@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.
-
@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 statethe pf rule is something like:
block drop in on WANWhat 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.
-
@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).
-
@steveits Good stuff. Thanks.
-
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.210Unsolicited 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.
-
@johnpoz I agree. I feel we are missing information and we have a fundamenal misunderstanding of want/possible/makes sense.
-
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
-
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.txtIn 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?
-
@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.
