LAN has no connectivity
-
@toddehb said in LAN has no connectivity:
I have enabled LAN2WAN outgoing NAT.
That shouldn't be needed, pfSense add necessary rule automatically.
Do you see a proper default gateway in Status > Gateways?
If so, run a packets capture on WAN while you try to ping 8.8.8.8 and post, what you get out.
-
Yes, default Gateway is WAN DHCP.
Packet capture gives this, when pinging 8.8.8.8
13:20:43.445104 IP XXX.83.56.123 > 8.8.8.8: ICMP echo request, id 53497, seq 25, length 64 13:20:43.445943 IP 8.8.8.8 > XXX.83.56.123: ICMP echo reply, id 53497, seq 25, length 64 13:20:44.469087 IP XXX.83.56.123 > 8.8.8.8: ICMP echo request, id 53497, seq 26, length 64 13:20:44.469919 IP 8.8.8.8 > XXX.83.56.123: ICMP echo reply, id 53497, seq 26, length 64 13:20:46.129059 IP XXX.83.56.123 > 8.8.8.8: ICMP echo request, id 10549, seq 1, length 64 13:20:46.129969 IP 8.8.8.8 > XXX.83.56.123: ICMP echo reply, id 10549, seq 1, length 64 13:20:47.157007 IP XXX.83.56.123 > 8.8.8.8: ICMP echo request, id 10549, seq 2, length 64 13:20:47.157839 IP 8.8.8.8 > XXX.83.56.123: ICMP echo reply, id 10549, seq 2, length 64 13:20:48.180983 IP XXX.83.56.123 > 8.8.8.8: ICMP echo request, id 10549, seq 3, length 64 13:20:48.181830 IP 8.8.8.8 > XXX.83.56.123: ICMP echo reply, id 10549, seq 3, length 64 13:20:49.204993 IP XXX.83.56.123 > 8.8.8.8: ICMP echo request, id 10549, seq 4, length 64 13:20:49.205872 IP 8.8.8.8 > XXX.83.56.123: ICMP echo reply, id 10549, seq 4, length 64 -
@toddehb
So you can see ICMP requests and replies on WAN. Did you ping from the LAN machine? If so, I can't believe that you get 100% packet loss. -
yes, pinged from the LAN machine.
There is no local firwall ( iptables etc. ) running on the client
ICMP request and replys are hitting the pfsense so I have no clue where else packets could get dropped, rejected or whatsoever
-
@toddehb
Did you state a gateway in the LAN interface settings?
If so you should remove it.Take a capture on the LAN interface while pinging to see if the response go out out properly.
-
@toddehb said in LAN has no connectivity:
I have enabled LAN2WAN outgoing NAT
Huh? There is nothing to do for this pfsense behind your 1st pfsense to have internet access. If its gateway is your first pfsense.
Unless you messed with the 1st pfsense outbound nat..
To your 1st pfsense, this 2nd pfsense is no different than any other client on your 1st pfsense lan.
-
@viragomann said in LAN has no connectivity:
@toddehb
Did you state a gateway in the LAN interface settings?
If so you should remove it.Take a capture on the LAN interface while pinging to see if the response go out out properly.
No gateway defined on LAN
Outbound NAT rules where created automatically
-
@johnpoz said in LAN has no connectivity:
@toddehb said in LAN has no connectivity:
I have enabled LAN2WAN outgoing NAT
Huh? There is nothing to do for this pfsense behind your 1st pfsense to have internet access. If its gateway is your first pfsense.
Unless you messed with the 1st pfsense outbound nat..
To your 1st pfsense, this 2nd pfsense is no different than any other client on your 1st pfsense lan.
There is only 1 pfsense in place .
-
@toddehb ok - not sure how I read that hehehe
But your device is just on pfsense lan.. There is nothing to do.. - what did you mean about you enabled lan2wan outgoing nat?
Do you have any rules on floating?
-
Well, expressed myself a little confusing. Not I enabled NAT, the system did as shown in the screenshot "auto created rule"
-
@toddehb what is your wan IP on your pfsense, its not a 10.x address itself is it?
What I would do is sniff on your pfsense wan while you pinging from this client to say 8.8.8.8 do you see that traffic going out your pfsense wan?
-
@toddehb said in LAN has no connectivity:
Well, expressed myself a little confusing. Not I enabled NAT, the system did as shown in the screenshot "auto created rule"
no, look at the screen witch icmp packets. I obfuscated the ip a little bit
-
Did a capture on LAN interface. Looks good to me
14:06:35.533408 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 4000.ec:13:db:42:a3:02.83fd, length 43 14:06:36.951555 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 1, length 64 14:06:36.952826 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 1, length 64 14:06:37.482424 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 4000.ec:13:db:42:a3:02.83fd, length 43 14:06:37.965989 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 2, length 64 14:06:37.967227 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 2, length 64 14:06:38.990013 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 3, length 64 14:06:38.994021 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 3, length 64 14:06:39.347396 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 4000.ec:13:db:42:a3:02.83fd, length 43 14:06:39.582728 IP 10.16.0.173.58226 > 4.2.2.1.53: UDP, length 50 14:06:39.582754 IP 10.16.0.173.58226 > 4.2.2.1.53: UDP, length 50 14:06:39.587955 IP 4.2.2.1.53 > 10.16.0.173.58226: UDP, length 113 14:06:39.589825 IP 4.2.2.1.53 > 10.16.0.173.58226: UDP, length 113 14:06:39.629909 ARP, Request who-has 10.16.0.172 tell 10.16.0.173, length 46 14:06:39.629917 ARP, Reply 10.16.0.172 is-at 00:22:1f:67:ee:4b, length 28 14:06:40.014032 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 4, length 64 14:06:40.014877 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 4, length 64 14:06:41.037968 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 5, length 64 14:06:41.038966 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 5, length 64 14:06:41.183358 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 4000.ec:13:db:42:a3:02.83fd, length 43 14:06:42.061955 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 6, length 64 14:06:42.062820 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 6, length 64 14:06:43.085975 IP 10.16.0.173 > 8.8.8.8: ICMP echo request, id 15, seq 7, length 64 14:06:43.086910 IP 8.8.8.8 > 10.16.0.173: ICMP echo reply, id 15, seq 7, length 64 14:06:43.118359 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 4000.ec:13:db:42:a3:02.83fd, length 43 -
@toddehb
So the responses go out on LAN properly to the VM IP.Check if the IP has the correct MAC in pfSense ARP table in Diagnostic > ARP.
Otherwise I can only imagine that there goes something wrong on HyperV. -
@toddehb so what is not working - looks like both your pings are working from that trace. I see both a ping reply from 8.8.8.8 and dns reply from the 4.2.2.1 etc.
-
@johnpoz said in LAN has no connectivity:
@toddehb so what is not working - looks like both your pings are working from that trace. I see both a ping reply from 8.8.8.8 and dns reply from the 4.2.2.1 etc.
The console is not showing any output when pinging. NSLOOKUP does not lookup and apt update eg. is not working. The system does not seem to have internet conenction.
-
@toddehb but from your sniff pfsense is sending on the reply to your ping and to your dns query.
So whatever the problem isn't a pfsense issue, it did what you asked, it sent on your ping and dns.. And when it got a reply it sent it back to the client that asked..
-
@johnpoz said in LAN has no connectivity:
@toddehb but from your sniff pfsense is sending on the reply to your ping and to your dns query.
So whatever the problem isn't a pfsense issue, it did what you asked, it sent on your ping and dns.. And when it got a reply it sent it back to the client that asked..
Yes, but cannot figure out what is going wrong. Did a reinstall on that VPS, same issue. Will contact support of Hoster. Maybe they know what is going on
-
Just want to update all on the solution. My hoster had some ebtable rules active which were actively blocking the traffic. They disbaled them and now everything is going smooth :
