pfsense appears to be calling Moldova when on site to site vpn
TKenny last edited by TKenny
I have no business running pfsense but I do anyway. I have a site to site vpn running with private internet access. I am using pfblocker and all sorts of blocklists including firehol.
Here is a screenshot of my alerts page for pfblocker. See all those calls after the first one?
The destination server doesn't seem all that threatening even though its on a block list. Still, whats it doing there? The source is always pfsense itself and the port numbers are always different between calls.
If I disconnect the site to site vpn these calls stop happening
It's only now occuring to me that bad actors could be looking at my network due to the vpn connection.
Lotsa questions for the patient among you:
- Why does my router appear to be trying to call this site?
- Is the site to site vpn the real source of these calls?
- Is there a firewall rule I could add that says, packets cannot come in from the site to site vpn unless they are responses to packets that I already sent out?
- Is there some other way to make a site to site vpn of this sort safer than Im starting to think it is?
![alt text](image url)
UDP to 53 is default port for DNS.. That could be a NS for any sort of domain that your doing queries on.. Out of the box pfsense resolves and could be trying to talk to authoritative ns for some domain.
I would sniff to see what the dns query is for..
I just came over here with the exact same setup and issue. I'm wondering if this is more related to PIA than anything else. I originally thought it was malware/botnet related on my internal network, so I'm glad that someone else is having the same issue.
Here's my logs for reference: Screenshot
So did you sniff to see what was it asking dns?
@johnpoz Using pfsense's built in packet capture and loading into wireshark, I was unable to even see the attempted connections. Data was captured with "promiscuous mode" enabled.
I'm assuming that since the firewall is dropping the traffic before it reaches the interface that this is why no data is captured to that IP range. Would I have to temporarily allow that traffic and then do the data capture? Limited experience with packet capture and analysis here.
You can capture traffic that is blocked all day long, you do not have to allow it to capture it. You have to sniff on the correct interface..
Your going to have to sniff on the PIA2 interface if you want to see what it is..
That looks like block on the outbound with that > in front of the interface. So your running rules in floating... Why would you block outbound, why would you not block it before it enters pfsense? Outbound rules really would only be needed to block the firewall from talking to something - and why would you do that?
So its prob something on your network trying to do that and your blocking it on the outbound out your vpn connection vs blocking it as the traffic comes into pfsense.. How exactly do you have these rules seutp?
If your blocking it from leaving (outbound) and your sniffing - since it never went on the wire, then you would prob never see it. But when you sniff on inbound traffic into an interface the sniff happens lower in the stack then when the block happens.
So yeah remove the block for a few minutes so you can capture some traffic and then you can put the block back. Or sniff as the traffic enters pfsense.
SixthGear last edited by SixthGear
@johnpoz I filter outbound for this reason...if something is infected on my network, I don't want it reaching out and connecting to the control server. Is this not a standard practice? I get the filtering inbound connections, but I thought it was also wise to filter outbound as well.
I completely disconnected every piece of networked hardware that I have from the pfsense unit, and the blocks were still happening. Also, the fact that someone that is also connecting to PIA via OpenVPN makes me think that it's not an infected machine but rather related to PIA itself. Here's a shot of my rules: Floating Ruleset
Is this not a standard practice? I get the filtering inbound connections, but I thought it was also wise to filter outbound as wel
Your not understanding how the rules work in pfsense. If you want to block clients on your network from going somewhere you would block it as it enters your lan interface.
Why let pfsense process traffic its just going to stop from leaving.. Just drop it before pfsense has to process it.
It could very well be the dns they hand out to vpn clients.. Allow the traffic and sniff it.. So you can see what it is.
@johnpoz I get what you are saying now regarding filtering it upon entering the lan interface.
Anyway, I was able to sniff the traffic and decode via Wireshark and it's listed as a standard DNS query unless I'm looking at it completely wrong.
Frame 232: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) Encapsulation type: NULL/Loopback (15) Arrival Time: Jul 26, 2018 04:56:59.101892000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1532599019.101892000 seconds [Time delta from previous captured frame: 0.104121000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 28.038005000 seconds] Frame Number: 232 Frame Length: 86 bytes (688 bits) Capture Length: 86 bytes (688 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: null:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Null/Loopback Family: IP (2) Internet Protocol Version 4, Src: 10.77.10.6, Dst: 188.8.131.52 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 82 Identification: 0x69aa (27050) Flags: 0x0000 0... .... .... .... = Reserved bit: Not set .0.. .... .... .... = Don't fragment: Not set ..0. .... .... .... = More fragments: Not set ...0 0000 0000 0000 = Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x29a3 [validation disabled] [Header checksum status: Unverified] Source: 10.77.10.6 Destination: 184.108.40.206 User Datagram Protocol, Src Port: 25688, Dst Port: 53 Source Port: 25688 Destination Port: 53 Length: 62 Checksum: 0xc186 [unverified] [Checksum Status: Unverified] [Stream index: 8] Domain Name System (query) Transaction ID: 0x1b25 Flags: 0x0010 Standard query 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...0 .... .... = Recursion desired: Don't do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...1 .... = Non-authenticated data: Acceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 1 Queries 220.127.116.11.in-addr.arpa: type PTR, class IN Name: 18.104.22.168.in-addr.arpa [Name Length: 25] [Label Count: 6] Type: PTR (domain name PoinTeR) (12) Class: IN (0x0001) Additional records <Root>: type OPT Name: <Root> Type: OPT (41) UDP payload size: 1472 Higher bits in extended RCODE: 0x00 EDNS0 version: 0 Z: 0x8000 1... .... .... .... = DO bit: Accepts DNSSEC security RRs .000 0000 0000 0000 = Reserved: 0x0000 Data length: 0
kpa last edited by
22.214.171.124.in-addr.arpa: type PTR, class IN
That's a standard reverse DNS query to figure out the FQDN associated with an IP address. The IP address 126.96.36.199 (read the query in reverse) seems to be located in the Netherlands.
Such reverse queries are a standard thing everytime a service needs to know the FQDN of an IP address and it does that by querying the registered entiry owning the IP address. It's very likely that someone from Moldova has done some probing on your firewall and it then does a query to the ISP located in Moldova in return to figure out the FQDN of the probing address.
Yeah that is a PTR query.. What other queries were in there, that doesn't give you much info..
Who is 10.77.10.6? Is that just your IP of your vpn connection? I would look on traffic as it enters pfsense to try and figure out who is creating that.
But since its a PTR for the IP your sending dns queries too.. Which that IP is different than your first listing.. Oh wait your different than the OP..
What other sort of other dns queries made other than PTR for IP your sending the query too. Which is typical for a client to send a PTR to the dns server is setup for so it knows the name of ns...
I don't show record for that specific IP, but the SOA for that network is
25.244.185.in-addr.arpa. 1799 IN SOA ns1.kvsolutions.nl.
Now while ns1 doesn't resolve, ns2 does which is the other listed NS for that domain
;; ANSWER SECTION:
ns2.kvsolutions.nl. 11785 IN A 188.8.131.52
;; QUESTION SECTION:
;kvsolutions.nl. IN NS
TKenny last edited by
Thanks to all for their helpful remarks. Amateurs like me get into trouble applying tons of block lists that then report on the most innocuous of things
Amateurs like me get into trouble applying tons of block
To be honest this is one of the things that just drives me NUTS!!! Why are you blocking when you don't understand.. All it does is cause you grief and pain ;)
How easy pfsense makes it to deploy advanced tools is both a blessing and curse ;)
Users think that hey click here and I have a IPS - this couldn't be farther from the truth.. Running an actual IPS/IDS takes understanding and skill which to be honest is beyond vast majority of users here on the forum.. To most users its going to do nothing but block shit they actually want and need to get access too and flood them with noise.
Same goes for pfblocker - while its a very powerful tool. To be honest most users have no need for it and will cause them grief.. What they are mostly after is blocking ads would be my guess. Which sure ok it can do but then they start clicking on every block list there is and then wondering WTF I can not get here or there, etc.. What are all these logs entries..
Your typical user should not install these advanced tools until they actually understand their use and how to use them.. While it can be catch 22 can not learn until they jump into the fire.
If you do not understand why something is being blocked - maybe you shouldn't be blocking it ;) This is not inbound traffic - this is traffic your own network is creating.. If you want to learn what is going on - log it and then sniff what is you see and ask hey why does this happen, what is this in the log mean..
We are all here to help for sure - love nothing more than helping the newb get the light bulb to click.. But most of the time its why is this blocked with zero info to help them figure out what it is ;)