Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have configured a fresh CentOS 6.2 installation on VMWare ESXi with an E1000 NIC, static IP, defined a correct default gateway, subnet mask, and DNS servers.

I use a pfSense as my virtual router/firewall and I can ping other hosts in the LAN net as well as hosts over the L2L VPN without issue.

However, when I try to ping 8.8.8.8 it fails. When performing a traceroute, the only hop it gets to is the first to 10.2.1.1 (the default gateway).

I have many Windows hosts behind the same firewall/router and they can connect to the Internet without issue. (If you cannot tell, I'm not a linux guy.)

I have confirmed that NetworkManager is not running.

I am scratching my head here - is it a VMWare issue? An MTU issue? CentOS issue?

EDIT 1: Now onto pfSense. Check in Edit log to see old content.

My routes table looks ok (blanked out my WAN default gateway, but it is right):

default xxx.xxx.xxx.xxx UGS 0   71607842    1500    em0
8.8.4.4 xxx.xxx.xxx.xxx UGHS    0   86984   1500    em0  
8.8.8.8 xxx.xxx.xxx.xxx UGHS    0   101336  1500    em0

And States filtered for 8.8.8.8

icmp    8.8.8.8:1551 <- 10.2.1.99   0:0 
icmp    10.2.1.99:1551 -> 10.2.1.1:38695 -> 8.8.8.8 0:0 
icmp    8.8.8.8:1714 <- 10.2.1.99   0:0 
icmp    10.2.1.99:1714 -> 10.2.1.1:61003 -> 8.8.8.8 0:0

All 0:0?

share|improve this question
1  
Can you confirm that your pfSense box is not blocking the traffic? –  Nic Young Mar 2 '12 at 6:15
    
Yes, it is not blocking traffic. Firewall logs are clear. I have other hosts set up in a similar fashion with no issue –  tacos_tacos_tacos Mar 2 '12 at 6:15
1  
Does it just time out when failing, or do you get an unreachable response from somewhere? I'd be inclined to point to an issue with the pfSense config first - is the traffic being sent over the VPN tunnel unintentionally? –  Shane Madden Mar 2 '12 at 6:17
    
Could you paste the content of /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/resolv.conf here please? Also, please paste the output of the netstat -rn command. –  Yanick Girouard Mar 2 '12 at 17:45
1  
Do a "tcpdump -e host 8.8.8.8" to filter on the traffic we're testing. Would it be possible to do something similar on the gateway, actually? I'm not convinced this is something you can diagnose from inside the Linux instance. –  cjc Mar 9 '12 at 20:04

1 Answer 1

up vote 3 down vote accepted
+50

You have a problem with NAT. In pfSense state table, the entries with three pieces should show: 1. Source IP, 2. NAT'ed IP, 3. Destination IP. In your case, the second piece is 10.2.1.1:X, which is the internal IP. You want to see the IP assigned to your pfSense by the ISP.

To confirm, try pinging from a working Windows system and compare the state table.

share|improve this answer
    
Thank you Max. The bounty is yours. In my CARP setup, I had a LAN address set for my advanced outbound NAT LAN-to-WAN rule rather than Interface address or another CARP address. Changing it fixed everything. –  tacos_tacos_tacos Mar 9 '12 at 21:17
    
Huzzah! So, the Linux instance's traffic was being sent to 8.8.8.8 without being NAT'ed? –  cjc Mar 9 '12 at 21:18
    
Yes, well in Advanced Outbound NAT, the address was set to 10.2.1.1, which was asinine of me. I changed this value to Interface Address as well as CARP shared address, and both worked. Basically, it wanted a WAN address to use there and I was giving it a local address –  tacos_tacos_tacos Mar 9 '12 at 21:21
    
@cjc It was NAT'ed but still using an internal IP rather than external. So 8.8.8.8 received a ping it couldn't route back to. Good catch Max –  Ryan Mar 9 '12 at 21:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.