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

Just did our second attempt to upgrade our ASG220.  Once again it has caused issues.  It looks like it only got to 7.100-581 and now the web admin doesn't work.  Everything appears to be working still, but I don't have any visability to fix anything.  I'm waiting on tech support for help getting it running again.  attempting to restart the httpd from console fails.

Our setup is really quite simple so not sure what the catch is.

Hopefully I don't need to make any changes right away.

Support had to fix out installation themselves. 

Appears that the system was missing the webadmin certificate information.  By adding the certificate back in the httpd webadmin process starts correctly now.

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 [:)]

Bruce,

You might be on to something.  I've had no success upgrading to v7.100 and my homegrown firewall uses two "Intel Corporation 82557/8/9 [Ethernet Pro 100]" NICs (1).

I'll try another rebuild in a day or two and post the results.

BillK


1.  Taken from Astaro's v7.011's Network >> Interfaces >> Hardware tab.

Well, it took me MUCH longer than I anticipated, but it looks like v7.103 fixed my issue (I had left myself on v7.011 until now)!  I'm going to wait until v7.104 loads, but if all goes well I plan to return the two new Netgear NICs I recently purchased.

I'm going to wait until v7.104 loads, but if all goes well I plan to return the two new Netgear NICs I recently purchased.

v7.104 loaded without a hitch, so back to the store the new NICs go.  Now I just need to figure out how to upgrade my network to GigE.   ;-)