Our Server is on inside network and people trying to use the FQDN to reach the server.
It is possible and how it is done properly with any issue?
Your server and clients need to be in different subnets and VLANs. Essentially what you are trying to accomplish is making sure that the entire traffic flow goes through the 3448. For example, if the server is 10.10.10.1/24 (VLAN 10), then the clients would need to be in 10.10.20.0/24 (VLAN 20). Then the 3448 would have subinterfaces or interface VLANs with IP addresses 10.10.10.254 and 10.10.20.254 where those IP addresses are the gateways for VLAN 10 and VLAN 20 respectively.
Hopefully that makes sense. Obviously there are multiple ways you could setup the routing with a 3448, so comment with further questions if you have any.
Are the people on the inside...
A corporate DNS could serve up the internal IP address and eliminate the need for internal client traffic to go out to the firewall and hairpin back in.
If you are using a public DNS, then you will get the public address on the outside of the firewall.
This brings up another question...
Is the public IP reserved for your server using 1:1 NAT, or are only certain tcp/udp ports sent through to it. (and is a single public address is shared by multiple internal servers and/or workstations)
Do your internal users use a different public IP address (NAT Pool) than the server's public address?
Glen
thanks for the reply
Here are more information
my FQDN is my WAN interface (eth0/2)
Vlan 1,2 & 3 are the client
Vlan 11 is the server
I have port forward certain TCP & UDP to the server.
Outside client no problem
Inside client is the issue
myfqdn.com is the WAN
Dont know where to start allow inside traffic to go out and in to same interface.
I hope this is possible....
Client using Public DNS
Port forward certain tcp/udp ports
Server & Client using same WAN IP add
Client is on Vlan 1,2 & 3
Server is on Vlan 11
FQDN = WAN interface (eth0/2)
Outside client using FQDN is OK
Inside Client using FQDN is the issue
Can we allow inside traffic to go out and back to same interface.
Do I have to add ip access-list on Private & Public
I just want to know if this is possible...
Here are some more information
Client using Public DNS
Port forward certain tcp/udp ports
Server & Client using same WAN IP add
Client is on Vlan 1,2 & 3
Server is on Vlan 11
FQDN = WAN interface (eth0/2)
Outside client using FQDN is OK
Inside Client using FQDN is the issue
Can we allow inside traffic to go out and back to same interface.
Do I have to add ip access-list on Private & Public
I just want to know if this is possible...
Hi jneri:
I don't believe AOS supports hairpin NAT. A possible solution (and arguably the most efficient design) is to configure your client VLAN interfaces into a Private policy-class (security zone), your server VLAN interface into its own zone (commonly called DMZ), and WAN interface into a Public zone. Setup firewall rules to allow or NAT traffic between the three classes/zones as appropriate (we can help you with that).
Then you need to setup internal DNS to be slightly different than your existing external FQDN. Your ADTRAN router can become the internal DNS server and provide the internal IP for your clients when they query the hostname, while forwarding other requests to external DNS servers. Inside clients will route to the server directly (internally) without NAT. Outside clients will continue to reach the server via NAT.
Do you think this could be feasible for your project?
Best,
Chris
A strict hairpin NAT is not supported, but in your configuration a similar type of functionality is possible. You shouldn't need to complicate this with internal DNS settings or DNS proxy configurations. All you need to do is make sure the clients and server are in different subnets, which you have already done.
This is how I do this.
Enable DNS on your server so you run your own dns for computers on the LAN
In the dns create the zone and host IP's for your server - these IPs will be the inside PRIVATE IP to the server
On your DHCP tell your PCs to use your LOCAL DNS server as the primary
Viola! Your, workstations will resolve the www.mycompany.com ip as 192.168.x.x or whatever it is that you put into the dns. I do this with all my routers and switches so I can access them by name instead of IP.
If you do not wan to do this, look into exporting a etc/hosts file to your workstations
The hosts file is querried before DNS
gl
jneri,
Please generate a feature request for this. Perhaps enough of them will get actual hairpin routing supported. The split DNS workaround will end up causing you frustration in the long run. It works in principle and for stationary machines will work fine, but If you have any mobile users who carry laptops around or wireless devices like cellphones and tablets inside your network you will find that the clients come online with a browser already open and DNS entries already cached in that browser and operating system dns cache. You will become very familiar with the procedure "close all browser windows, ipconfig /flushdns and reopen the browser" or reboot. So far, the only actual workaround I have found is to use policy based routing to route this traffic out a second backup WAN connection so that it is actually external traffic.