traffic in wan
-
@gertjan said in traffic in wan:
Then how passes this traffic "destination port 31599" through your ISP router ?
on router is open port 10443 1194 and 9022
NO USE DMZ.
I need help to determine if facebook is trying something unauthorized against my pfsense or just normal traffic.
-
@viragomann It can help me to get out of doubt ...
-
@silence
Obviously you get requests form 72.238.67.3 to 31.13.71.1:443 from a client connected to your OpenVPN server.
These are directed out to your WAN correctly and it gets your WAN address, which 31.13.71.1 is responding to. But for what ever reason pfSense obviously has not set a state and the traffic is blocked by your WAN Deny_All_To_Any rule. So presumably without this rule, it would by blocked by the Default_deny rule anyway.I'm wondering if the traffic from public source IPs is really desired on your VPN server.
However, basically this should work, but obviously pfSense has no state for the connection, when the response is coming back.
Maybe it has something to do with the scheduled rule, which is allowing it and the rule was just closed.
If that's the reason, ensure that System > Advanced > Miscellaneous > Schedule States is unchecked. -
@viragomann said in traffic in wan:
But for what ever reason pfSense obviously has not set a state and the traffic is blocked
If you send out a connection out a VPN, how would the destination your talking to even know your wan IP? And no there would be no state if sent out traffic connection A, and answer came in connection B.
He still hasn't answered the question about the VPN and how its being used. How would he be sending traffic out a VPN server connection?
He doesn't even have a LAN interface listed.. So really curious on what kind of setup he has.. Where is this client that is going to facebook? Is this client some vpn client, connecting to pfsense, and its routing the traffic out its wan to facebook?
How and the F is pfsense seeing this traffic on its 192.168.1.254 address?
How is traffic coming into his VPN server public space? And going to 31.13? and not being natted to his 192.168 address - which would create the state..
A diagram of this setup would be most helpful..
-
@johnpoz said in traffic in wan:
If you send out a connection out a VPN, how would the destination your talking to even know your wan IP?
Because of masquerading. pfSense translates the source, when sending the packet out on WAN and then the ISP route translates it to its public IP.
How is traffic coming into his VPN server public space? And going to 31.13? and not being natted to his 192.168 address - which would create the state..
It's thinkable that a client, who is connected to his VPN server, forwards this to him. He is accepting any source IP on the OpenVPN interface and so the client can send him whatever source he want.
A diagram of this setup would be most helpful..
Agree, still too few details.
-
@viragomann said in traffic in wan:
source IP on the OpenVPN interface and so the client can send him whatever source he want.
Not how it works.. The client of the vpn server would get an IP from the vpn server (the tunnel network)..
Unless he has some downstream clients using this vpn connection..
We really need a drawing, and understand where these "clients" are that are using pfsense to get to facebook..
Are these clients in some remote location and getting to pfsense via a site to site vpn? Why are they using a Charter Communications, Inc public IP? That 72.238 IP.
Even if that is the case, pfsense would still nat the traffic trying to go to facebook to its 192.168.1.254 address. So there should be a state - look to your state table for states going to this 31 address.
It seems he does have his connections allowed through some schedule.. Is that schedule killing states every minute or something... When do these blocked logged entries show up? All the time, only at the end of the schedule when states are killed.
Here is what I can tell you - if pfsense sent traffic out its wan to that 31 address there should be a state created, if there wasn't nothing would work... He says stuff is working, but if at some point those states are killed then incoming return traffic would be blocked as out of state.
Facebook sure and the hell is not going to be sending you traffic to some random port from a source of 443.. You have requested this traffic, it is in answer to your traffic.. Why you would be blocking it is there is no state, either it was never created - if that is the case how would it work, or its being killed off and that is when its showing the block in the log.
-
@johnpoz, @viragomann @Gertjan
Sorry for the delay, it is very involved in the investigation, and I want to confirm that everything works 100% but even so I continue to receive this traffic during the day.
-
@silence said in traffic in wan:
https: //files. fm/u/7kcgvm8ag#/view/xjswpx877
@Gertjan @viragomann @johnpoz in case you didn't see it ...
-
@silence where did you get the idea to use
72.238.67.0/24
As your tunnel network?? That make zero sense.. Where is the rest of the info? Use a rfc1918 address for your tunnel, not some public route-able address owned by COX.
Where are you outbound nats? So you have some client that comes in and then you had him a public IP, and then show us firewalls then with such info makes zero sense..
Where is your state table - again does this happen all the time, only at specific times per your schedule where your resetting states?
You have no lan - who exactly are these clients? They sure and the hell are not getting to pfsense to talk to a vpn when it has 192.168.1.254 as its wan, so you have something in front of pfsense and your forwarding traffic, etc..
Nobody can help you without info.
-
@johnpoz said in traffic in wan:
where did you get the idea to use
72.238.67.0/24This is necessary to bypass a ** rfc1918 address ** lock
Where are you outbound nats? = Default
Where is your state table - again does this happen all the time, only at specific times per your schedule where your resetting states?
this happens randomly throughout the day ... maybe 2 or 3 packets a day.
You have no lan - who exactly are these clients? They sure and the hell are not getting to pfsense to talk to a vpn when it has 192.168.1.254 as its wan, so you have something in front of pfsense and your forwarding traffic, etc..
There is no lan, it is a vpn within 192.168.1.254 This sends everything through its gateway 192.168.1.1 and it has 2 ports open for the vpn.
this is all the configuration you want to know the most?
-
@silence Dude look in your state table!! You will see traffic to that IP.. Your sending traffic to facebook via QUIC..
Validate that by looking for traffic going thee.. Create an rule that you log so you can see
If the return traffic, which clearly this natting router in front of you sent... Does not have a state in pfsense - for what reason? Then it would be blocked.
But sure and the hell is not facebook trying to spy on you from source port 443.. The traffic could never even get to pfsense unless your router in front of it had a state to send to you.. Because you created the traffic too them.
-
-
@silence that is ALL out of state traffic... See the SA (syn,ack) so for whatever reason pfsense never saw the SYN to create the state..
So something talked to that 17 address, without going through pfsense so it knew about the traffic and created the state.
-
@johnpoz said in traffic in wan:
So something talked to that 17 address,
@johnpoz, In conclusion: should I continue with the same firewall rules? or do I have to allow this type of traffic?
Could this cause a problem? or just ignore it?
-
@johnpoz said in traffic in wan:
So something talked to that 17 address, without going through pfsense
But why goes the respond to his pfSense and why does the internet router let it pass?
Is it not a stateful firewall? -
@silence said in traffic in wan:
or do I have to allow this type of traffic?
No you should never need to allow out of state traffic.. Other than some very specific use cases where the network is borked anyway ;)
I would be more curious to why your seeing it in the first place - you have some odd routing with your unique vpn setup.. And use of public IPs in your tunnel. You have a issue with your states being reset or not created? You have some schedule clearly setup for "business hours" is this clearing states?
Out of state is just that, either pfsense never saw the syn in the first place - why? If the traffic is suppose to be flowing through pfsense. Or the states got reset, which if were ACKs ok, but those are all syn,ack - which would be first response to the destination seeing the syn.. So the states are never being created because pfsense never saw the syn, or it did but didn't create the state?
Is odd traffic to be sure - but I sure and the hell wouldn't go allowing out of state traffic because you have some firewall log entries.. And gain your "users" have no complaints of anything be slow or not working?
-
@johnpoz said in traffic in wan:
And gain your "users" have no complaints of anything be slow or not working?
Exactly, nobody is complaining about anything and in the firewall you continue to see this type of traffic.
