How is the up2date from 7.011 to 7.1 going for you?

Not good.

We have had two important NAT/DNAT setups fail as a result of the update, and we are still waiting for support to get back to us on how to fix them.  
1) we have a DNAT rule that allows an external DB to replicates to an internal server
The replication is pulled from the internal server, and was supported by a packet filter rule for MySQL and an SNAT rule:

SNAT [DB Replication]
Traffic selector: Internal (Address) → MySQL → [External server name]
Source translation: Milliways MySQL

Ever since the update to 7.101, this replication now fails.

Additionally, we had a FULL NAT (plus packet filter rules), to allow external SSH access from a specific network, to an internal set of servers in a DMZ. It all used to work, but now, oddly, we can SSH to the servers themselves in the DMZ, but not to the VMs (virtual machines) on the servers, even though they are in the same subnet.  I can SSH from machine to virtual within the subnet so I know the routing and interfaces on the boxes are configured correctly, but I can't even SSH from my LAN to the VMs on the DMZ.

I'm still waiting for support to sort this out. It's been days.  Anyone experience anything similar? Where DNAT/SNAT rule-based routing just stopped working?  Not all of our routes have failed. Just those two.  Our mail uses a similar route to our Exchange server, and it's still working.

-Natalie

Are you using interface bindings in your network definitions?

Kind regards,
Daniel

(STILL no word from Astaro support on this, BTW. *argh*)

We have four interfaces defined in our network definitions:  Internal, External, External2, and DMZ.  

According to support, any interface defined should automatically be added to internal routes, so I shouldn't have to add a route from my internal LAN to the DMZ, and that appears to be true, at least for the hosts...

I have 4 FULL NAT rules in place for external access to the hosts/VMs, with automatic packet filter rules.  The NAT rules do not reference the interfaces, they use hosts only.
In any case, they only come into play when our contractor tries to access the DMZ servers from their offices (and the NAT rules are tied to their IP address range).

That being said, I can't even get this to work from my LAN, and the contractor experiences EXACTLY the same behavior when they come in from their offices.

Here's the setup:

I have 3 servers in a DMZ on a 172.16.1.0 subnet off an interface on Eth5 (interface: DMZ)
My LAN is on 192.168.7.0 subnet (interface: INTERNAL).

One of the servers in the DMZ, FLINT, runs VMWare.  FLINT's internal IP is 172.16.1.4
FLINT's VM IP is 172.16.1.41

I can SSH from the LAN to FLINT
I can SSH from the LAN to CORTEX (on the same DMZ subnet as FLINT)
I can SSH from CORTEX to both FLINT and FLINTVM

I CANNOT SSH from the LAN to FLINTVM

The same is true of external SSH access, and we need to be able to get to FLINTVM.

I don't believe it is a VM or internal server routing issue, because otherwise I wouldn't be able to SSH to FLINTVM from anywhere.  It's only when I try to go through the ASG that it fails.  

This WAS all working prior to the update to 7.101

Any ideas?

Well, I finally got support from Astaro and got as far as resolving the issue with connecting to the VM in the DMZ from within the LAN. Some kind fo policy route was interfering (a policy route that was required and didn't interfere before the update, btw).  

However, we still don't have outbound connectivity from anything in the DMZ to the outside world.  We were trying to use a second external (pppoe) interface with additionally assigned addresses, but that totally didn't work.  

Then I tried using one of the spare IP addresses off my primary external interface (and default GW) with no success.  I cannot do something as simple as ping outbound from the boxes in the DMZ, nor can I connect to them via SSH.

I have tried all manner of policy routes, static routes, checked the gateways on the servers in the DMZ, nothing seems to work.


And TRULY weird is the routing we see on a traceroute.

I have a our Primary interface on a Cable Modem from ISP #1 - labelled "External"
Our secondary interface on a PPPOE DSL connection from ISP #2 - labelled "External2"

If I tracert to an IP address on External2 interface (ISP #2) , the final visible step in the traceroute is the primary External interface's IP address (off ISP #1).  It's like the ASG is somehow confusing the routing internally and trying to reply/route back out through the primary gateway.  Any ideas on what we can do to fix this?

-Natalie

If you watch the live packet filter log, do you see the traffic getting to the packet filter?  Is it handled there?

Well, I finally got support from Astaro and got as far as resolving the issue with connecting to the VM in the DMZ from within the LAN. Some kind fo policy route was interfering (a policy route that was required and didn't interfere before the update, btw).  

However, we still don't have outbound connectivity from anything in the DMZ to the outside world.  We were trying to use a second external (pppoe) interface with additionally assigned addresses, but that totally didn't work.  

Then I tried using one of the spare IP addresses off my primary external interface (and default GW) with no success.  I cannot do something as simple as ping outbound from the boxes in the DMZ, nor can I connect to them via SSH.

I have tried all manner of policy routes, static routes, checked the gateways on the servers in the DMZ, nothing seems to work.


And TRULY weird is the routing we see on a traceroute.

I have a our Primary interface on a Cable Modem from ISP #1 - labelled "External"
Our secondary interface on a PPPOE DSL connection from ISP #2 - labelled "External2"

If I tracert to an IP address on External2 interface (ISP #2) , the final visible step in the traceroute is the primary External interface's IP address (off ISP #1).  It's like the ASG is somehow confusing the routing internally and trying to reply/route back out through the primary gateway.  Any ideas on what we can do to fix this?

-Natalie

Your outbound traffic isn't going via the proxy is it? If so that will 'only' route traffic via the default gateway which would be your "external" interface not "External2". Just a thought anyhow [:)]

Well, I finally got support from Astaro and got as far as resolving the issue with connecting to the VM in the DMZ from within the LAN. Some kind fo policy route was interfering (a policy route that was required and didn't interfere before the update, btw).  

However, we still don't have outbound connectivity from anything in the DMZ to the outside world.  We were trying to use a second external (pppoe) interface with additionally assigned addresses, but that totally didn't work.  

Then I tried using one of the spare IP addresses off my primary external interface (and default GW) with no success.  I cannot do something as simple as ping outbound from the boxes in the DMZ, nor can I connect to them via SSH.

I have tried all manner of policy routes, static routes, checked the gateways on the servers in the DMZ, nothing seems to work.


And TRULY weird is the routing we see on a traceroute.

I have a our Primary interface on a Cable Modem from ISP #1 - labelled "External"
Our secondary interface on a PPPOE DSL connection from ISP #2 - labelled "External2"

If I tracert to an IP address on External2 interface (ISP #2) , the final visible step in the traceroute is the primary External interface's IP address (off ISP #1).  It's like the ASG is somehow confusing the routing internally and trying to reply/route back out through the primary gateway.  Any ideas on what we can do to fix this?

-Natalie

Your outbound traffic isn't going via the proxy is it? If so that will 'only' route traffic via the default gateway which would be your "external" interface not "External2". Just a thought anyhow [:)]