Bridged WAN-DMZ pings intermittent
-
DMZ-WAN bridge issues: I'm having lots of trouble getting remote access to a server on a DMZ that is bridged to a WAN port. Incoming pings work for a while then stop. A band-aid, that seems to work, is a script on the DMZ server that pings an address on the Internet. That seems to keep door open. An alias IP address, on the DMZ server, also had access issues until I started outgoing 60 second pings sourced from that address too. It looks like it might be an ARP issue with the WAN - cable modem link. Any ideas?
-
It's bridged so you have public addresses on the DMZ machine (and virtual IPs)?
How do you have bridge filtering setup?Steve
-
My system is configured with a public IP on the WAN interface, outgoing NAT on a LAN interface with an outgoing NAT rule that maps source address matching the LAN subnet to the WAN interface address.
There is a DMZ interface, with no address, that uses Bridge0 WAN-DMZ.
The cable modem has the 1st usable address in the public subnet, WAN the 2nd, and the rest for use on the DMZ port.
I've found that I need proxy arp for addresses on the DMZ (arp -s IP MAC pub or an entry under Virtual IPs.)
A proxy arp entry solves my problem with incoming access to the DMZ addresses.
Unfortunately, I am still having trouble with incoming access to the WAN address (ping, ssh, openvpn). It works and then stops. If I force a ping from one of the DMZ servers to an Internet address, the WAN address can be accessed again. If the pings keep running, everything is fine. If I stop the pings, eventually remote access to the WAN address fails. I'm about ready to add a script on the firewall to ping something all the time. It looks like an arp issue with the cable modem WAN link. The firewall won't let me add an arp entry for the cable modem address. I'm not sure what to try next without risking a remote lockout.
-
What NICs do you have?
Do you have filtering on the bridge members or the bridge interface or both?
Steve
-
The hardware is a Dell R320 with a 4 port Intel Pro/1000VT. The internal nics are disabled and it's running pfsense 2.0.3
The first WAN rule is icmp any to WAN subnet
The only DMZ rule is any to any
The only Bridge0 rule is any to any -
Are seeing anything in the logs like is reported in this thread:
http://forum.pfsense.org/index.php/topic,66908.0.htmlIt's obviously not the same problem since you are able to get some traffic.
Steve
-
My problem seems a lot like others are having with bridging on the same device. I don't see any of the log entries you referenced. I thought I'd try bringing up the built in Ethernet devices. I rebooted with them enabled, unfortunately they aren't recognized.
dmesg …
pci2: <network, ethernet="">at device 0.0 (no driver attached)
pci2: <network, ethernet="">at device 0.1 (no driver attached)pciconf -l ....
class=0x020000 card=0x04f71028 chip=0x165f14e4They appear to be some type of Broadcom. I thought bge would work but something must be different on a Dell R320.
At this point external traffic to DMZ servers works but external to WAN console and Openvpn is unstable and only works some of the time. Outgoing traffic seems to fix the problem.
It seems like getting the internal ports to work or replacing the Intel Pro1000VT PCI express card with something are my only ideas. I'd try 2.1 Release but the last RC wouldn't boot and I didn't have time or access to investigate.</network,></network,>
-
Ooops. So many posts about 2.1 in the last week I just assumed you were running that and that was the cause of your problem. I need to read more thoroughly! :-[
In that case it's probably nothing to do with the thread I linked to which seems to be an issue introduced with 2.1.
I would encourage you to try 2.1 again. It can probably be made to boot. Do you remember what the issue was last time? Just be aware of the potential bridge issue with em NICs.
Steve
-
I believe 2.1RC2 booted the USB stick, installed and then did a panic during the disk boot (geom raid 1). I think I'm going to remove the bridge and put the DMZ on a private subnet and do some 1:1 nat. Hopefully, that will fix the intermittent issues with the WAN interface.. If I had hands on access I'd probably try again with 2.1 and put up a better fight. I just didn't know the release was coming so quick.