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.

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

Can you please post screenshots of your NAT rules, and your PacketFilter rules?

Have you read the NAT howto already?

Barry

Ah,

now its getting clearer, Pix can do that via the proxy arp feature. Why are you using NAT anyway from A to B, as they both on a private subnet-range you normally can route  between them. 

As far I remeber, there are two ways to solve, either use a Wins server in network A, so the domain controllers can see the clients via network neigborhood. Or you put the Astaro into bridging mode, and expand the subnets, so the clients and servers are in one subnet. 

Chris

Barry: I have read the NAT docs. I know it's working because I can establish a remote desktop connection to the server behind the firewall unsing the NAT address. Furthermore, the server can surf the net so I know outbound is OK too.

Chris: There are a couple of reasons why I have this topology. One is because I don't have control over routing in our network. I would need a route in subnet Bs router to point subnet A at the firewall. This is our production network and I don't want to mess around with it. Yes, they are both private, but the core router doesn't know how to get to it.

The other is because I want to test this solution with NAT. I want to be able to make it work with or without it. it could come in handy in an extranet situation where the outside is pointing to a partner or client and the inside is our network.

If I read you correctly it doesn't sound as if I can accomplish what I'm attempting. I'm trying to stay away from adding more infrastructure than I have to (WINS server, etc...) In bridging mode, doesn't the inside and outside use the same subnet? If that's the case then it doesn't solve my isolation or extranet scenarios. I turned on the proxy arp feature in ASL but it doesn't seem to help, although admittedly, I don't fully understand how it works in ASL.

Thanks,
John

John,
NAT should work for what you are doing.

There's no DROPs or REJECTs in your log posted, so all I can guess at this point is that perhaps VMWare is confusing something.

Barry

Hi, 

Berry, ARP is below the packet-filter. The trouble he has, is that the DC needs a mac-address of a host that wishes to join the domain. So also the request from the client reaches the DC, the DC cant find the mac-address of the client, because the Astaro wont give it to the DC. 

Theoretically, the DC should take the mac of the Astaro interface, because the Client is in a foreign network, and the Astaro interface is the door to get there. But well its Microsoft.

John, Arp-Proxy is similar to bridge mode in the effect, that a client thinks, he can communicate directly with a host, but in reality he communicates via the firewall. But therefore, they have to be in the same subnet of course. 
So if you dont want to change your net, I fear you have to put in the mac addresses manually on your DC. But you can get the mac-addresse from the astaro, just like in windows with arp -a. So it shouldnt be to much work making a batch file on the DC that inserts them into the arp-table. 

Chris

OK... There must be a way to tell the DC not to track MACs though?

How do VPN users connect to DCs?

Barry

Don't think you can add a client via VPN to a AD, but you should be able to connect to a AD if your client is allready a member of the domain. 

Chris

Don't think you can add a client via VPN to a AD, but you should be able to connect to a AD if your client is allready a member of the domain. 

Chris