pfSense sends packet as 0.0.0.0
-
Hi,
I've a strange problem with my pfSense. It works quite well, but is seems having trouble connecting to Internet.If I perform a ping from GUI, it doesn't work if I leave selected "automatic" as source address. If I force to select the "WAN" interface, it works.
routing etc is ok: I can administer pfSense from the Internet, and also I have two VPN IPSEC up and running.
With packet sniffer I found that it's sending packets with IP "0.0.0.0" as source.
I cannot find any way to understand this :(
any idea?thanks
-
@Topogigio said in pfSense sends packet as 0.0.0.0:
0.0.0.0"
You can do a packet capture from pfSense, Diagnostics -> Packet Capture.
Are they DHCP requests, check out the port number:-
16:01:03.019810 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:01:03.020074 IP 172.16.2.1.67 > 172.16.2.41.68: UDP, length 300If you change the level of detail you'll see more info like the mac address where the 0.0.0.0 is comming from.
-
@NogBadTheBad no: from one window I try to ping 1.1.1.1, on a second window I capture packets with filter=host 1.1.1.1
What I see is that pfSense is sending ICMP request with 0.0.0.0 as source IP.
It seems that NAT is not working.
As workaround I tried to apply a manual NAT mapping rule "from source=any -> NAT with WAN address" and this fix the problem. If the same rule has "this firewall (itself)" as source filter instead of any, it does not work.
My outgoing NAT mode is Hybrid and automatic rule with "127.0.0.0/8" as source is present. -
Does the ping work from pfSense if you say the WAN interface is the source ?
-
@NogBadTheBad yes, with this selection works
-
Should just work out the box with automatic rules.
You should have your LAN subnets in the automatic rules as well.
-
@NogBadTheBad yes, all seems right. But still it does not work.
-
Post a screen shot of your NAT rules and your LAN rules.
You can just drag and drop them into the chat window.
-
@NogBadTheBad NAT outgoing:
The last mapping is what I added as workaround.
Previous two are specific rules (working well) for two specific hosts in the LAN that need specific outgoing IP address. -
@NogBadTheBad rules LAN
-
Curious why do you have 2 specific IPs in your auto outbound nats? 10.77.36.1 and .5
What specific IP of client where you pinging from to 1.1.1.1 when you saw the outbound from 0.0.0.0?
And your hybrid, so you have specific vips on your wan?
Trying to figure out how your auto rules match up to your networks.. From your rules I see only 2 interfaces. So that would be 2 networks in auto. If it was showing your 2 ipsec, why do you only have 3 there should be 4?? And if the singles are your ipsec? Where is the 3rd range coming from..
So yeah a bit confusing...
-
@johnpoz I was pinging from pfSense itself, not from a client. From clients works.
Yes I have some additional VIPs
Yes I have two LANs + two IPSECs. LANs are 10.77.32.0/26 and 10.77.32.64/26. 10.77.36.1 and .5 are IPs on the point-to-point IPSEC tunnels. 172.30.98.0/24 is a subnet on the remote side of IPSEC (this is strange, yes).
However as I said the problem is not from the connected networks. The problem is only from pfSense itself.
-
Can we see an example in a pcap?
-
@Topogigio said in pfSense sends packet as 0.0.0.0:
but is seems having trouble connecting to Internet.
In what manner? Are you saying it can not check for updates? Unbound is not working... What is not working.. Other than when you do a manual ping, you say you see source of all zeros? When you don't pick an interface?
-
@johnpoz I noticed the problem because it was unable to populate the available package list..
So I noticed that it was unable to resolve DNS, then that was unable to ping, and so on.
After the outpoing NAT rule I added as workaround all started to work. -
so when you remove that rule, it doesn't work anymore? Or maybe unbound just had an issue? If you can not resolve.. Did you see dns traffic going out with all zeros as source?
-
- You should never have an outbound NAT rule with a source of
any-- fix that before anything else. You are in hybrid mode so it's unnecessary anyhow. - Let's see the pcap, or a screenshot of it loaded in wireshark
- What shows up in Diagnostics > States for the traffic that is sourced as
0.0.0.0?
The last time this happened there was something unusual on the user's setup, though I can't remember what it was. I want to say maybe it was an IPv6-only IPsec VTI instance but I'm probably misremembering.
- You should never have an outbound NAT rule with a source of
-
@johnpoz If I remove that rule, it does not work anymore. If I remove that rule I see traffic (ICMP request for example) from pfSense with 0.0.0.0 as source. Only traffic from pfSense itself, not traffic from other hosts routed through it.
-
- I know it. I added it as workaround, without that pfSense is unable to contact the world to resolve DNS or download updates.
- sorry, a pcap from where? I have access to pfSense and nothing else on the external side.
From the pfSense:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
15:37:32.819751 IP 0.0.0.0 > 8.8.8.8: ICMP echo request, id 32851, seq 0, length 64
15:37:33.830224 IP 0.0.0.0 > 8.8.8.8: ICMP echo request, id 32851, seq 1, length 64
15:37:34.840837 IP 0.0.0.0 > 8.8.8.8: ICMP echo request, id 32851, seq 2, length 64states: I cannot find anything related to 8.8.8.8
I have IPSEC VTI interfaces, but I'm sure that the problem has started AFTER I configured them (because I required OSPF so I installed the package after the VPNs were connected. However can be something there, I agree. But I cannot understand why and what..
-
No states shown for 0.0.0.0 either?
