NAT Problem

Those local packets are not traversing the firewall, so the firewall cannot possibly get a chance to translate them.

Do you need this functionality??

I really need this feature, because the server needs to be able to see itself under the external ip address and as long as i can remember it used to be able to see itself. i cannot remember if i had MASQ or SNAT turned on, but i also tried MASQ now and it does not work as well.
Is there any souloution?

Since those packets are not traversing Astaro's address translation stack, the solution will not be forthcoming from Astaro; that has to be addressed in the server's network settings.

One trick way to do that is to add that 134 address as an additional one on that server's NIC (this is called multi-homing; it can occur on a single NIC or multiple NICs).

What OS are you running?

Thank you very much.  I added the 134 IP-Address as an additional Address on the servers NIC and it finally works =)
I did not think this could actually work, but it really does.

Thanks again and it is W2K3 Server Enterprise btw.

I was happy too soon. Since i applied the 134 IP-Address the other Networks within the ASL could not see the Server anymore. Just from the outside.
Any ideas?

Ohh; I was unaware that other NICs need to access it by that IP also.

That gets more complicated; you can also do DNAT rules for each NIC, translating the 134 address to the 192 address. Or if it's just a few Windows machines, you can add the definition by name as a 192 address to their hosts or lmhosts file. You can even set the definition up in one file on a share and reference it in those host files using an include directive (look at the comments in those files).

Give me some bigger picture (Zeitgeist, for our German readers who strain to read this); why do they need to access it by that IP; why can't you have them access by the 192 address? Because they are using an external DNS and the record is programmed that way? It might be easier to use an internal DNS you manage, and then define the address for that box to be the 192 number; queries outside your domain can then be passed off to the external DNS (this is a "split DNS" topology...)

The networks behind the other NICs cannot access the server with the external 134 Address nor with the internal 192.168.7.1 or .2 Adresses when i give the network card the 134 address as an additional ip. The Server needs to be able to access itself with the external IP-Address because it's active directory has the external domainname and needs to be able to contact it with this external domain-name.
I tried to look behind what you wrote first: "Those local packets are not traversing the firewall, so the firewall cannot possibly get a chance to translate them."
They must be passing the firewall, because the server does not know that the 134 Address is himself.
Here's his routing table:
IPv4-Routentabelle
===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 0e 0c 22 0b 8d ...... Intel(R) PRO/1000 MT Network Connection
0x10004 ...00 0e a6 4b 1a 18 ...... 3Com Gigabit LOM (3C940)
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0    192.168.7.254      192.168.7.1     10
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
      169.254.0.0      255.255.0.0   169.254.94.131   169.254.94.131     20
   169.254.94.131  255.255.255.255        127.0.0.1        127.0.0.1     20
  169.254.255.255  255.255.255.255   169.254.94.131   169.254.94.131     20
      192.168.7.0    255.255.255.0      192.168.7.1      192.168.7.1     10
      192.168.7.1  255.255.255.255        127.0.0.1        127.0.0.1     10
      192.168.7.2  255.255.255.255        127.0.0.1        127.0.0.1     10
    192.168.7.255  255.255.255.255      192.168.7.1      192.168.7.1     10
        224.0.0.0        240.0.0.0   169.254.94.131   169.254.94.131     20
        224.0.0.0        240.0.0.0      192.168.7.1      192.168.7.1     10
  255.255.255.255  255.255.255.255   169.254.94.131   169.254.94.131      1
  255.255.255.255  255.255.255.255      192.168.7.1      192.168.7.1      1
Standardgateway:     192.168.7.254
===========================================================================

The Server has the 192.168.7.1 and .2 the 169 is the automatic Address of a second Networkcard that is not in use right now.

For my understanding this is an error in the ASL routing.

The server will see that it is that address and access itself no problem.

Your other machines (which I was unaware of) will not be able to access it by that 134 IP (especially on the same LAN as the server), unless you also multi-home those or implicitly tell them to stop using the 134 address by using

• an internal DNS
  
• modified hosts (or lmhosts files, in the case of Windows)
  

[/list]

I thought yuou only needed access of that address from the server, so that's why I shared that trick. For access from everywhere, you really have to clean-up the name to address resolution mechanism for your network.

in my understanding the server does not know that the 134 address is himself, so he sends the packet to his standard gateway which is the ASL. The ASL should be able to see that it is the same machine and redirect the packets back to the server at his internal ip address (applying the packet filter rules). the server itself should not have anything to do with it, since it does not know that it is trying to reach itself.
The internal DNS cannot be used, because this is also an external DNS and the 134 ip address is not managed by me.
The thing that surprises me is that when i apply the 134 address as an aditional on the server, i cannot reach it from another network within asl through its internal 192.168.7.1 address. just from the outside with the 134 ip...

"the server does not know that the 134 address is himself,..."

But if it is multihomed, it should...

PCs on the LAN won't know, because they can't see that the server is multihomed unless that info is published in DNS or hosts files. And even then, they won't talk that to that 134 IP unless they are also multihomed.

Rather than multihoming everything, make an overriding IP to address entry in your hosts files or an internal DNS server.

Windows DNS lets you do this. It's not a walk in the park, but a DNS server can be configured to give different responses based on who is doing the querying (i.e., what is the source IP of the DNS query). So queries made by PCs on you LAN will get the 192 address, and queries coming from all other IP networks get another address.

As for queries made from other internal (192) NICs, you will have to set up a DNAT rule for each NIC or set up the DNS to also pass back the 192 address for those other 192 networks.

Then test that the PCs are using the correct IP address (192) by pinging by the server's name...

Many people prefer to do split DNS using two DNS servers, as opposed to one (which some people like for its centralized configuration). The IPs meant for public consumption are kept at a server managed by your ISP, and the internal server consults external DNS servers for addresses not under the jurisdiction of your domain. This prevents somebody on the net from poisoning your internal server's cache.