Block ICMP on WAN Interface good idea?
-
Some services, for example OpenVPN, need ICMP to discovery the MTU.
So the question is, allow all ICMP types on the WAN interface or only some types?Is it a security issue to allow ANY ICMP traffic?
-
mtu discover does not need all types of icmp.. Buy why would an inbound rule on your firewall blick pfsense from sending back a icmp answer that packet had to be fragmented if you send do not fragment.
Why would it matter on pfsense to be honest, your biggest problem with path discovery would be along the path that could not send full sized packets. Not the actual end point. Is your mtu smaller than normal at openvpn/pfsense side?
-
Not the actual end point. Is your mtu smaller than normal at openvpn/pfsense side?
Good question, I don't know at the moment.
I asking because i have a OpenVPN server which a lot of clients around the world.
One of them connect the OpenVPN tunnel (UDP) and can ping without a issue inside the tunnel, but the line go immediatly down as soon i start a VNC or http traffic across the tunnel.
Try fragment 1200 / mssfix no chance.But the crazy thing is, "one day" of the month the tunnel work over hours without a problem.
-
How does that have anything to do with your mtu size? If your tunnel is up its up.. This is issue is with 1 client.. How is it have anything to do with your settings.. If it was pfsense then none of your clients would work or report the same problem, or atleast a vast majority of them would.
Where is the client around the world - maybe their internet connection just blows chucks.. Like most of the 3rd world does ;)
-
@slu:
Some services, for example OpenVPN, need ICMP to discovery the MTU.
So the question is, allow all ICMP types on the WAN interface or only some types?Is it a security issue to allow ANY ICMP traffic?
I've been wondering about this also. My system is set up to allow echo-req, but what is best practice for incoming icmp (both 4 and 6)?
-
How does that have anything to do with your mtu size? If your tunnel is up its up.. This is issue is with 1 client.. How is it have anything to do with your settings..
I see this sometimes as soon there is traffic on the OpenVPN connection, mostly fragment 1300 help but not in this case.
Where is the client around the world - maybe their internet connection just blows chucks.. Like most of the 3rd world does ;)
I guess this is a problem on the client side, but since this is our customer this doesn't help me :-\
At the moment i setup a second OpenVPN server over TCP, ping need a bit longer but the connection is stable so far.
Back to the theme with the ICMP, I open now:
- destination unreachable
- echo request
- echo reply
There is nothing in the pfSense book about this, if it is no security risk I will open ICMP ANY.
-
So how exactly is echo reply going to be inbound to pfsense wan interface, that is not in answer to a ping created by pfsense?
You need to look at what the direction of the traffic is, who is the requester who is the responder. Is the traffic generated directly from pfsense wan IP or is it something that is from client inside pfsense? So a destination unreachable. When would you need this to be allowed to pfsense wan?
As to icmp being a security issue - comes down to how tight your tinfoil hat is ;) But understanding the different aspects of icmp and when and where they are used is key to making your security decision..
As to your vpn issue, yeah tcp is way more capable of dealing with bad connection.. While udp is not as forgiving.. TCP will retrans, udp – hey just throwing them packets over the wall.. Hope you get them..
-
You need to look at what the direction of the traffic is, who is the requester who is the responder.
Ah, now I understand.
Need a incoming rule for the ping request (Internet -> WAN -> pfSense) and pfSense can send the reply, right?So a destination unreachable. When would you need this to be allowed to pfsense wan?
https://docs.openvpn.net/how-to-tutorialsguides/administration/troubleshooting-openvpn-connectivity-issues/
My OpenVPN work now fine with TCP.
