LAN has no connectivity

toddehb

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

viragomann

@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.

toddehb

@viragomann

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

viragomann

@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.

johnpoz

@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.

toddehb

@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

toddehb

@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 .

johnpoz

@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?

toddehb

@johnpoz

Well, expressed myself a little confusing. Not I enabled NAT, the system did as shown in the screenshot "auto created rule"

johnpoz

@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

@toddehb said in LAN has no connectivity:

@johnpoz

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

toddehb

@toddehb

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

viragomann

@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.

johnpoz

@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.

toddehb

@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.

johnpoz

@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..

toddehb

@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

toddehb

@toddehb

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 :