Weird issue with OPT1 internet access
-
"the issue is getting HTTP access going from this server to the outside world"
Then why do you have a 1:1 nat setup?? You do understand this is point and click working… So something stupid your over looking..
-
"the issue is getting HTTP access going from this server to the outside world"
Then why do you have a 1:1 nat setup?? You do understand this is point and click working… So something stupid your over looking..
The 1:1 was added to assign this server an inbound/outbound IP for usage later. Yes I understand that once there is an allow any rule it should be all working as expected but it isn't and I know there must be something stupid I am overlooking but I cannot seem to figure out what. Hence my post here.
I have started again by demoting the Windows server and destroying the domain.
pfsense has 5 interfaces:
WAN
LAN - 10.0.0.0/24
OPT1 (VMLAN) - 10.0.5.0/24
OPT2 (VLAN10) - 10.0.10.0/24
OPT3 (VLAN20) - 10.0.20.0/24Windows Server is on VMLAN:
10.0.5.2
GW: 10.0.5.1
DNS: 10.0.5.1Outbound NAT is set to automatic:
ICMP requests from the Windows server are working fine as are DNS requests but HTTP is not even though the Network and Sharing Center states that there is Internet access.
Windows Firewall is turned off for all connection types, IE enhanced security configuration is also disabled for administrators (which is the account in use).If I create a firewall rule on VMLAN to log requests on port 80 I can see that this is passed on the firewall log although the server gets "Page can't be displayed"… I'm stumped because everything seems to be correct.
-
Try tcpdump on your external interface to make sure it requests the page correctly?
-
Try tcpdump on your external interface to make sure it requests the page correctly?
172.16.0.78 being the pfsense LAN address assigned from the modem (WAN)
16:28:48.909893 aa:b7:69:52:a3:ec > 00:37:b7:15:a2:66, ethertype IPv4 (0x0800), length 66: (tos 0x2,ECT(0), ttl 127, id 8896, offset 0, flags [DF], proto TCP (6), length 52) 172.16.0.78.4737 > 31.55.166.216.80: Flags [SEW], cksum 0x8c89 (correct), seq 655046013, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 16:28:48.928957 00:37:b7:15:a2:66 > aa:b7:69:52:a3:ec, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 57, id 7244, offset 0, flags [none], proto TCP (6), length 52) 31.55.166.216.80 > 172.16.0.78.4737: Flags [S.], cksum 0x8c1d (correct), seq 3750408064, ack 655046014, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:28:48.929576 aa:b7:69:52:a3:ec > 00:37:b7:15:a2:66, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 8897, offset 0, flags [DF], proto TCP (6), length 40) 172.16.0.78.4737 > 31.55.166.216.80: Flags [.], cksum 0xe5a2 (incorrect -> 0x3b00), seq 1, ack 1, win 1024, length 0 16:28:48.929689 aa:b7:69:52:a3:ec > 00:37:b7:15:a2:66, ethertype IPv4 (0x0800), length 301: (tos 0x0, ttl 127, id 8898, offset 0, flags [DF], proto TCP (6), length 287) 172.16.0.78.4737 > 31.55.166.216.80: Flags [P.], cksum 0xe699 (incorrect -> 0x5581), seq 1:248, ack 1, win 1024, length 247 16:28:49.242823 aa:b7:69:52:a3:ec > 00:37:b7:15:a2:66, ethertype IPv4 (0x0800), length 301: (tos 0x0, ttl 127, id 8899, offset 0, flags [DF], proto TCP (6), length 287) 172.16.0.78.4737 > 31.55.166.216.80: Flags [P.], cksum 0xe699 (incorrect -> 0x5581), seq 1:248, ack 1, win 1024, length 247 16:28:49.852286 aa:b7:69:52:a3:ec > 00:37:b7:15:a2:66, ethertype IPv4 (0x0800), length 301: (tos 0x0, ttl 127, id 8900, offset 0, flags [DF], proto TCP (6), length 287) 172.16.0.78.4737 > 31.55.166.216.80: Flags [P.], cksum 0xe699 (incorrect -> 0x5581), seq 1:248, ack 1, win 1024, length 247 16:28:51.055344 aa:b7:69:52:a3:ec > 00:37:b7:15:a2:66, ethertype IPv4 (0x0800), length 301: (tos 0x0, ttl 127, id 8901, offset 0, flags [DF], proto TCP (6), length 287) 172.16.0.78.4737 > 31.55.166.216.80: Flags [P.], cksum 0xe699 (incorrect -> 0x5581), seq 1:248, ack 1, win 1024, length 247 -
Seems that my issue may be related to: https://forum.pfsense.org/index.php?topic=85797.0
Reply #4 from cmb suggests that I shouldn't have xn nics when I do, running pfsense 2.2.3 and XenServer 6.5. I have now disabled hardware checksum offload (System -> Advanced -> Networking) and disabled ethtool-tx on all VIFs attached to the pf vm with no luck…
UPDATE: That post mentions to do it for rx as well which has fixed my issue! Thanks all.
-
So your issue is you were running on xenserver.. But did not mention that anywhere ;) until now..
-
So your issue is you were running on xenserver.. But did not mention that anywhere ;) until now..
I did mention it was on a vm on my first post, just forgot to mention the hv… Apologies :-[
-
Those incorrect checkums in your tcpdump do look creepy.. :)
I have no experience with XenServer but can't you use a different type of NIC ? (for example an intel e1000 or so?)
-
Those incorrect checkums in your tcpdump do look creepy.. :)
I have no experience with XenServer but can't you use a different type of NIC ? (for example an intel e1000 or so?)
We use Broadcom NetXtreme BCM5720 Gigabit, I have a feeling that this is a XenTools issue…
-
Yes, that's your hardware NIC. But can you try to reconfigure your pfsense virtual machine to use a different nic-model/type? (not sure if that's possible but I'd think so)
That way it won't use the XenTools/virtual nic.
-
simple search here on pfsense forums for xenserver would of pointed you to many threads with pointing out the checksum problems.
There is even a Sticky in the VM section
https://forum.pfsense.org/index.php?topic=88467.0
