traffic in wan
-
@silence what is that rule, that is not the default rule..
So that is inbound traffic to your pfsense IP 192.168.1.254, from that 443 port.. Source of 443 is odd as source port, would be more like an answer to something you requested..
QUIC uses UDP over 443..
https://peering.google.com/#/learn-more/quic
So I would guess that is some answer to something you requested on that 31 IP. But its blocked because there is no state for that traffic.
edit: seems facebook is playing with quic
https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/ -
@johnpoz, The question is?
is this a problem or is it normal?
since my vpn client have no problem using facebook or any other apps.
-
@silence It seems odd that if you were using facebook app or website through your vpn that you would be seeing traffic to your wan interface. From IP y our talking to through the vpn.
So something is not quite right. If you were flowing outbound through a vpn.. How would it know your actual wan IP?
But then again not sure how you have your vpn setup, that sure looks like a server interface in your first log, but if you were using a vpn service it should be a client interface cX..
Without more details of your setup, and what your doing with facebook its hard to tell what is actually going on.
But that IP is for sure a facebook IP.
;; ANSWER SECTION: 1.71.13.31.in-addr.arpa. 3600 IN PTR edge-star-shv-01-lga3.facebook.com. -
@johnpoz, I always see the same sequence ...
-
@silence So how would you be sending traffic from that 72 IP to 31, and then 31 through some server connection, and then getting an answer back on pfsense wan.
How do you have your vpn setup... If you were using some vpn service, that would be a client setup in pfsense. Do you have some site 2 site setup with some server elsewhere?
If your flowing through a vpn, how would facebook know your wan IP to even send anything? Something in their client reporting something?
-
-
@johnpoz said in traffic in wan:
So how would you be sending traffic from that 72 IP to 31, and then 31 through some server connection, and then getting an answer back on pfsense wan.
This is what I am trying to find out, what is really going on?
because everything seems to work 100%
-
-
@silence said in traffic in wan:
NO DMZ
Then how passes this traffic "destination port 31599" through your ISP router ?
No NAT rules on that router ?@silence said in traffic in wan:
Any suggestion?
Yep, a suggestion - not a solution.
First things first : Status > System Logs > Settings :
Uncheck :
Rules on your WAN interface : don't make them log.
And enjoy the silence ^^
@johnpoz said in traffic in wan:
seems facebook is playing
My advise : refuse their 'games' ;)
-
-
@silence no they weren't, the default is all checked except the default pass.
I have setup pfsense countless times.. And here this is a default VM setup not that long ago..
-
@johnpoz said in traffic in wan:
@silence no they weren't, the default is all checked except the default pass.
I think they are not understanding me,
first: from the beginning of the installation uncheck these options
second: I think they are straying a bit from the main question!
-
@gertjan said in traffic in wan:
My advise : refuse their 'games' ;)
@johnpoz dice
@gertjan said in traffic in wan:
seems facebook is playing
I don't understand what you mean by which facebook is playing?
I'm just trying to come to the conclusion!
-
@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.
