HELP! Can I give ASL an IP alias?

Hi Justin,

download version 2.0!

read you 
o|iver

Thanks for your reply.

Are you saying I can't do it without going to Version 2.0?

I just have a firm belief in "if it ain't broke..."

Justin.
xxxxxx

Another step.  Another problem.
I have succeeded in assigning an IP alias to the external interface, by using "ip addr add...".  I haven't put that command in a script to run at boot because I don't know how yet, but that's a different problem.
Having added the IP alias, the Internet can see and access my FTP site properly   [:)] .
However, I can't!
I can access the FTP site using its real address from within my internal network, but using the proper name (ftpsite.domain_name.com) the clients inside the network cannot use it.
I expected that as DNAT is used for this address, it would be translated correctly in both directions regardless of which interface the packet arrived at, but it appears not.  Am I making a mistake or is this a bug?

Justin.
xxxxxx

Have you set SNAT or masqerading for the offending host/network?

Thank you for your reply Elliot.
No, I haven't enabled any SNAT at all.  I have used DNAT to translate the external public IP to the internal address of the FTP server in the DMZ, and for accesses from outside this works.  However, as I think you've guessed, I have used Masquerading for the other (main) private network.  This is probably what's wrong, but I thought that the DNAT rule would translate the public address to the internal DMZ address first of all, causing it to be directed to that interface.  If I use the real internal address of the FTP server from within the private network, it works fine.
At the moment I have a work-around by adding the real internal address to the hosts file of all the clients.
I really appreciate any help you can offer me with this.

Justin.
xxxxxx

hi justin,

you are suffering from the effect described here:
 http://docs.astaro.org/asl-faq.pl#4014 

/tom

Thank you for your reply Tom.
The effect you describe, quoted below, is reasonable enough:
   

quote:

---

#4014 I have trouble connecting to DNATed services from clients inside my LAN when I use a DNS or server name. What can I do ?
    A: This is most probably a generic problem with DNAT, DNS and routing.
     Example:
  
       Your external ASL interface has the IP 1.2.3.4
       Your webserver inside the LAN has the IP 192.168.1.10
       You have added a DNAT rule to translate
              1.2.3.4:80 -> 192.168.1.10:80
       Your server name "www.myserver.com" resolves to 1.2.3.4
       
       Symptoms: External clients can browse the web server fine, but
       internal clients can only connect if they use the IP address instead
       of the name or they cannot connect at all.
       
       Cause: The web server is in the same network as the clients, but
       its name resolves to an external address. Thus, the web server will
       answer connections from the LAN clients directly with his internal
       interface address (192.168.1.10) But the clients expect the answer
       from the external address (1.2.3.4) which they contacted in the
       first place.
       
       Solution 1: Put the web server in a different logical network,
       separated from the LAN (in our case, maybe 192.168.2.10).
       
       Solution 2: Make sure the name "www.myserver.com" resolves into
       the internal address of the webserver for all clients in your
       LAN (via extra DNS server or static hosts file entry).
 

---

However, I already have my FTP server (in this case) in a DMZ on a different network, as described in solution 1.
I can only guess that I've missed something that nobody else bothers to mention because it's so obvious!

Justin.
xxxxxx

[ 25 September 2001: Message edited by: Justin Wheatley ]

[ 25 September 2001: Message edited by: Justin Wheatley ]

Thank you for your reply Tom.
The effect you describe, quoted below, is reasonable enough:
   

quote:

---

#4014 I have trouble connecting to DNATed services from clients inside my LAN when I use a DNS or server name. What can I do ?
    A: This is most probably a generic problem with DNAT, DNS and routing.
     Example:
  
       Your external ASL interface has the IP 1.2.3.4
       Your webserver inside the LAN has the IP 192.168.1.10
       You have added a DNAT rule to translate
              1.2.3.4:80 -> 192.168.1.10:80
       Your server name "www.myserver.com" resolves to 1.2.3.4
       
       Symptoms: External clients can browse the web server fine, but
       internal clients can only connect if they use the IP address instead
       of the name or they cannot connect at all.
       
       Cause: The web server is in the same network as the clients, but
       its name resolves to an external address. Thus, the web server will
       answer connections from the LAN clients directly with his internal
       interface address (192.168.1.10) But the clients expect the answer
       from the external address (1.2.3.4) which they contacted in the
       first place.
       
       Solution 1: Put the web server in a different logical network,
       separated from the LAN (in our case, maybe 192.168.2.10).
       
       Solution 2: Make sure the name "www.myserver.com" resolves into
       the internal address of the webserver for all clients in your
       LAN (via extra DNS server or static hosts file entry).
 

---

However, I already have my FTP server (in this case) in a DMZ on a different network, as described in solution 1.
I can only guess that I've missed something that nobody else bothers to mention because it's so obvious!

Justin.
xxxxxx

[ 25 September 2001: Message edited by: Justin Wheatley ]

[ 25 September 2001: Message edited by: Justin Wheatley ]

Hi Justin,

I think you are missing the "Solution 2" you posted from the FAQ.
When you send a request to the IP address of your server, it comes back to you with a correct answer since there is no name resolving required.

When you try with ftp.yourserver.com, the request gets resolved by your DNS server (or your ISPs' DNS server), to the real IP, that is located on your ASLs' external NIC, and than DNATted to the server. Your request reaches your server but never gets back to you with an answer since it tryes to answer a query that arrived from the external IP.

The solution for this is adding an extra DNS server that serves all the LAN clients, and in which you define, much like in the hosts files, the internal IPs' of your servers. If you don't have extra hardware for running another DNS server (if at all) you can solve it with the hosts files on your client computers. If your LAN is big, you can use your DNS server with the latest version of BIND and IPv6, which enables you to set which zone will listen on which IP, allowing you to serve both internal & external IPs from the same server.

I hope this will help
Maurice

Thank you Maurice.  As my LAN is quite small I have settled with the HOSTS file solution as I can't be doing with setting-up an internal DNS server.  There are flaws in this approach as you indicate, but at the end of the day if you're going to spend less time smoothing over the flaws than you will spend creating a proper fix, that's perhaps the one the boss would prefer!

I appreciate your kind and thorough reply.

Justin.
xxxxxx