03-25-2011 06:22 PM
I see all the elements you need here but there is one extra one you need to remove.
set route 18.104.22.168/32 interface ethernet0/3
This is the route you would need if the public address was in a DIFFERENT subnet than your interface address. Your ip address is in the SAME range. As a result you have a built in route for that subnet to the untrust eth0/0 interface already. When you put the above route into the trust interface you override this build in route and break the nat-dst.
You have the proxy arp, address entry and policy all correct as outlined in kb12631. I believe when you remove this static route it will work.
I was curious as to why your default route is not inthe same subnet as your eth0/0 interface.
03-29-2011 12:25 AM
OK, I tried moving the server to the DMZ zone, and adjusting the policy, and it still does not work. To be honest, I feel like I am going down a rat hole on this one, because everytime I go back to the documentation it seems to emphasize that the external interface of the firewall needs to be on a separate subnet to the public IP addresses of the servers. Also, I actually need to configure 4 address translations, not one. I have two servers, each with two network cards, and I need to configure NAT for all of them. I keep feeling that MIP is the way to go. Right now I'm beginning to have fond memories of the old SunScreen product, and I never thought I would say that. It gave me headaches at the time, but it was simple compared to this.
03-29-2011 12:27 AM
Still no joy. I'm going to rip out the config and start again tomorrow. I might give the bidirectional NAT instructions in KB11911 a shot, and see if they work.
03-29-2011 03:17 AM
Sorry this is turning into such an ordeal for you. You have the internal address in the DMZ znoe which is fine. But you have created the public address there too and the policy as untrust to DMZ. When the pubic address is in the same subnet as the interface the policy is untrust to untrust.
I promise that I have used the procedure outlined in kb12631 for addresses in the same subnet as a public interface and it does work. The references you see to not being in the same subnet are that you need a different method for the actual interface ip address. If you need to use this address in port forwarding you can only use the VIP procedures not this policy nat-dst or MIP.
For the same subnet the route is a connected automatic route that you do not need to create but you do need to use proxy-arp which you have in this connfiguration.
version 6.3 as you have it
set interface ethernet0/0 proxy-arp-entry 22.214.171.124 126.96.36.199
version 6.2 and earlier
set arp nat-dst
The public address object is created in the untrust zone. These all move to untrust.
set address "DMZ" "linux_admin" 188.8.131.52 255.255.255.255
set address "DMZ" "linux_prod" 184.108.40.206 255.255.255.255
set address "DMZ" "windows_admin" 220.127.116.11 255.255.255.255
set address "DMZ" "windows_prod" 18.104.22.168 255.255.255.255
The policy is then untrust to untrust and the internal ip address is entered raw from any connected zone.
set policy id 7 name "Translation" from "Untrust" to "DMZ" "Any" "linux_admin" "ANY" nat dst ip 10.77.40.11 permit log
03-29-2011 11:59 PM - edited 03-30-2011 01:34 AM
OK, so I tried that, and it didn't work. Then I tried setting up MIPs, see GSNS_MIPconfig.txt, and that didn't work. I've tried changing the external interfaces to one of the addresses that I want to use for translation (after removing all the MIPs and policies etc), and pinging the next hop router, but that doesn't seem to be helping. If I have the ethernet0/0 manage address on 22.214.171.124 and the ethernet0/0 address itself on 126.96.36.199 (see Basic_confg.txt), I can connect to the firewall on the manage IP address, and not on the main address. I can ping 188.8.131.52, but not 184.108.40.206 from the internet.
I think I have pretty much exhausted all possibilities. This has consumed hours of time to no good effect, and I see no prospect of it ever working. I suspect that the firewall is not answering ARP requests for anything but the .20 address, and I seem to have no way pratical to fix that. I do not have access to the data centre, and in any case I am reluctant to implement a solution that involves mucking about trying to manually teach a router that I don't control new ARP entries. The first time the router gets rebooted, the whole thing will fall apart, and I may not be on hand to fix it.
04-06-2011 09:05 AM - edited 04-06-2011 09:07 AM
I hit your post because I'm having a horrible time with policy based dst-nat and proxy arp. I need this type of setup because I have many IPs and need to leverage ALG for SIP, but after reading your initial post I think you're sniffing down the wrong path with proxy ARP or MIP for that matter.
Everyone howls when they see someone suggest VIP, but it just magically works. Here are the steps in the GUI to setup simple "port forwarding" like you'd expect it to work. I use the GUI mostly, which can be buggy, but it's always worked fine for me.
From scratch config:
- Ensure the trust interface is setup in NAT, not ROUTE configuration. This is the default, but some people change it immediately. This keeps your trust interface set up as Interface NAT, not policy NAT.
- Assign a public IP to the untrust interface using the proper subnet mask
- Setup a default route (0.0.0.0/0) through the physical untrust interface to the proper upstream gateway IP
- Create a VIP (Interfaces/List/Edit/VIP) that is "Same as the interface IP address" - Do this first before adding any other public IPs from your subnet.
- Once the VIPs have been created, create VIP services using the New VIP Service button. This is where you setup the service ports and target IP address. The target can be in the trust or dmz zone.
- Once you create your VIPs and VIP services, add a simple policies from Untrust to Trust from ANY to VIP (the VIP addresses will be listed in the drop-down, prefixed with VIP) with traffic/service of ANY. No need to go to the advanced section, the policy is not there to determine traffic type, just allow traffic to move across zones for the VIPs. The VIP Services you've created will determine what traffic for what ports are allowed to move through the router.
- If you have VIP service targets in the dmz zone, you may have to setup a simple policy that allows ANY traffic from Trust to DMZ. You will also have to setup a policy to allow traffic from DMZ to Untrust, but this one will have to be source-natted so click the Advanced buttton and check the Source Translastion box with None-Use Egress Port as the DIP setting.
Hope that made sense. This has always worked for me for simple remote access setups. There are limitations to the number of VIPs you can setup and the number of VIP services you can setup, but I've rarely had a problem hitting those limits.