ARP

Hi,

how should NAT respond to ARP?

Chris

Let me clarify a little. I want the firewall to respond to ARP requests since the NAT lives on the firewall. Otherwise, how can traffic ever get to the firewall, let alone the NAT. The machine that I'm using to administer, as well as test the NAT sits on the same segment as the FWs eth0 (outside) so no routing is necessary. Most of the time, no amount of probing will get the firewall to respond to an ARP request. Therefore, I get no web console or inbound NAT traffic unless I add a static ARP entry in my local table.

Hi,

ARP only works on a link (or in other words same subnet). 
So normaly the firewall, knows the mac-address of all of his direct linked networks. 
The only mac address a internal client needs to know, is the mac of his default-gw, to reach an external target. The same with the Firewall, it only needs to know the mac of its default gateway.
So a internal client will never see a mac-address of an external target, because it is off the link.

Chris

That makes sense. I'll give you a couple of specific examples of my problem. 

Case#1: I boot my laptop in the morning (clean ARP table). I attempt to connect to the webadmin (both machines on the same subnet), cannot connect. I ping the IP of the ASL box, no response. In fact when I do an arp -a while pinging the table has 00-00-00-00-00-00 for the ASL host. While sniffing this whole process I see my laptop ARPing for the ASLs MAC, no reponse. I statically add the MAC, everything works. 

Case#2: I have a host on the inside that is attempting to join a domain. I have temporarily opened up all traffic for testing purposes (se there should be no problem there). When I initiate the join domain process, I can see the ldap packets hitting the DC. The DC is, in turn, ARPing for the MAC of the sending host, in this case the NAT. There is no reply.

Shouldn't something be replying to the ARP requests. ARP tables don't populate themselves with all available MACs, they are added as needed. Furthermore, ARP entries are dynamic, they expire or need to be refreshed periodically, so it's up to the individual hosts on a network to identify themselves.

This is the only host on my network that behaves this way. Again, the ASL is running in a VM. Could that be the issue. I have many other VMs that work jsut fine on my network though. I'm wondering if ASL has issues while running in a VM.

Thanks,
John

Are you using standard or bridged/transparent mode?

Are you using DHCP? Where is your DHCP server?

Please draw a diagram of your network.

Barry

The FW is in standard (routing) mode.

No DHCP, all static.

FW
|
Hub ---- DC
|
PC

Doesn't get any more complicated than that. There are obviously many more devices connected to the hub but they were omitted since they bear no relevance to this problem.

The other annoying part of this problem is that I also need static routes on my devices in order to talk to the NAT. This will be very problematic if I try to deploy this on a network with hundreds of hosts.

Something seems wrong with your config...

If you're doing NAT to talk from PC To DC, then I'm _guessing_ you're trying to run multiple subnets on your hub.

You can't do that. The spoofing detection will trigger on ASL and kill all connections.

Alternatives:
Set it up with a real DMZ, if that's what you're trying to do.
Get a VLAN switch.

I really don't understand why you'd want the DC to be on a different network though, unless you're going to be using a VPN.

Barry

Let me expand the drawing a little (maybe a little clearer):

PC (Subnet A)
|
FW (NAT A-B)
|
Hub (Subnet B) ---- DC
|
Laptop (webadmin)

As you can see I am not running two different subnets on a hub. I have one subnet behind the firewall and another that's common to the firewall, DC and my laptop. I don't want to use a VPN, I simply want the PC behind the firewall to join a domain on a DC residing on the other side of the firewall.

I've done this countless times with PIX firewalls, it's not a novel idea. As long as the appropriate ports are open (in this case, all) then the connection should be made. On tis note, I do see the LDAP traffic leaving the client, passing through the firewall and hitting the DC, but since the DC doesn't know the MAC address of the client, it cannot respond.

I have the DC on a different subnet because I want to isolate the PC from the rest of the network but still want to leverage domain authentication.

John

OK... that picture makes more sense.

It should fine in that config, assuming you've created appropriate packet filter rules allowing traffic through.

Have you looked at the packetfilter log?

Barry

The packet filter rule is  "Allow Client --> Any:Any". I have looked at the log. Here are some entries from today (IPs scrubbed):

2005:09:12-09:46:07 (none) ulogd[398]: ACCEPT: IN=eth1 OUT=eth0 MAC=00:0c:29[:D]1:f1:f2:00:0c:29:4e:f4:0b:08:00 SRC=Client DST=DC1 LEN=66 TOS=00 PREC=0x00 TTL=127 ID=217 PROTO=UDP SPT=1039 DPT=53 LEN=46 
2005:09:12-09:46:50 (none) ulogd[398]: ACCEPT: IN=eth1 OUT=eth0 MAC=00:0c:29[:D]1:f1:f2:00:0c:29:4e:f4:0b:08:00 SRC=Client DST=DC1 LEN=92 TOS=00 PREC=0x00 TTL=127 ID=224 PROTO=UDP SPT=1040 DPT=53 LEN=72 
2005:09:12-09:46:56 (none) ulogd[398]: ACCEPT: IN=eth1 OUT=eth0 MAC=00:0c:29[:D]1:f1:f2:00:0c:29:4e:f4:0b:08:00 SRC=Client DST=DC2 LEN=166 TOS=00 PREC=0x00 TTL=127 ID=235 PROTO=UDP SPT=1043 DPT=389 LEN=146 
2005:09:12-09:46:56 (none) ulogd[398]: ACCEPT: IN=eth1 OUT=eth0 MAC=00:0c:29[:D]1:f1:f2:00:0c:29:4e:f4:0b:08:00 SRC=Client DST=DC1 LEN=166 TOS=00 PREC=0x00 TTL=127 ID=238 PROTO=UDP SPT=1046 DPT=389 LEN=146 
2005:09:12-09:47:00 (none) ulogd[398]: ACCEPT: IN=eth1 OUT=eth0 MAC=00:0c:29[:D]1:f1:f2:00:0c:29:4e:f4:0b:08:00 SRC=Client DST=DC2 LEN=166 TOS=00 PREC=0x00 TTL=127 ID=250 PROTO=UDP SPT=1054 DPT=389 LEN=146 
2005:09:12-09:47:00 (none) ulogd[398]: ACCEPT: IN=eth1 OUT=eth0 MAC=00:0c:29[:D]1:f1:f2:00:0c:29:4e:f4:0b:08:00 SRC=Client DST=DC1 LEN=166 TOS=00 PREC=0x00 TTL=127 ID=251 PROTO=UDP SPT=1055 DPT=389 LEN=146

As can be seen, the DNS lookup occurs and then the LDAP traffic attempts to connect. Here's a snip from a sniff that captures the other side of the firewall:

1 0.000000    DC2 Broadcast ARP  Who has NAT?  Tell DC2
2 0.113921    DC1 Broadcast ARP  Who has NAT?  Tell DC1
3 4.951000    DC2 Broadcast ARP  Who has NAT?  Tell DC2
4 5.062063    DC1 Broadcast ARP  Who has NAT?  Tell DC1
5 9.907910    DC2 Broadcast ARP  Who has NAT?  Tell DC2
6 10.016407   DC1 Broadcast ARP  Who has NAT?  Tell DC1

Now we can see that the DCs are requesting the MAC address of the NAT. Seeing no response the connection does not get established.

John