Astaro “ICMP Destination unreachable (Fragmentation needed)” Problems

Problem:

Twice now my Astaro Security Gateway VMWare Virtual Appliance performance has dramatically decreased any traffic through and reports “ICMP x.x.x.x unreachable - need to frag (mtu 1500)”

Solution:

Change your VMWare virtual appliance network adapters from the pre-configured “Flexible” to “E1000” by editing the .vmx file.

Description:

I have four virtual machines that run on VMWare ESX 4. One of these VM’s is the ASG virtual appliance connected to a public (Internet) interface and a private (virtual network) interface. Each of the remaining three systems are connected to the private virtual network as well. One is a web server, another a database server.

Using a DNAT rule I make my web server accessible to external (Internet) users. Using the SSL VPN I made my database server accessible to internal (company) users.

For some reason, and after performing very well for months, the ASG starts exhibitng awful performance is passing the traffic back and forth. Web pages that external users try to access rarely display and more often timeout. (Interesting note is that Windows clients seems to timeout 93% but Mac clients display the web page, after a few extra seconds, 99% of the time).

Users connected via SSL VPN and accessing the database server also see horrible performance as well. If I do a SCP of a 3MB file from the database server to my laptop over the SSL VPN it transfers in 30 seconds. However uploading this same 3MB file from my laptop to the database server requires a transfer time of 12 minutes!

The ASG stats show very little load on the system during these transfers:

CPU: 4%
RAM: 31%
Swap: 1%
Log disk: 2%
Data disk: 5%

Using SSH on the Astaro I run a tcpdump to see what’s going on. I’m able to narrow it down by using:

tcpdump -ni any -s0 -v -f 'icmp[icmptype] == 3 and icmp[icmpcode] == 4'

After shutting down the ASG virtual appliance, then changing the network adapter type to “E1000” and restarting the ASG virtual appliance the problem vanishes.

Astaro Support Rant

At this point I just want to rant a little about Astaro Support. I’ve been working with Astaro products since 2005 and really, really like them. They’ve always been, in my opinion, an EXCELLENT value for the feature set you receive and the price that you pay, just excellent.

In those 6 years I’ve worked with Astaro products (6 different Astaro product installs) I’ve had to contact their support about 10 times, which I don’t think is bad. In almost all cases the support follow-up, communication and technical ability of the engineers has really been excellent.

However, in the past four months I’ve had to contact Astaro three times. In each instance the response and communication was pathetic, meaning that I either didn’t hear anything from Astaro or I had to call them to get any response.

In another instance I opened a ticket on July 6th, received a response back on that same day with some comments on the case, exchanged a few more emails on the 6th and 7th, then I didn’t receive another response until July 15th!

I called Astaro support again and spoke to a gentlemen that said all of the engineers were in a meeting and weren’t available.  He said he would note the case and leave a note on the engineers desk to have him call me back after the meeting.  I didn’t receive a phone call that day before I left at 5:40pm nor later then evening although I had my work phone forwarded to my cell expecting the call.

The next day, Thursday, I called again.  I spoke to the same gentlemen that wasn’t sure why the engineer hadn’t contacted me.  He said the engineer wouldn’t arrive until later today, as he does west coast support, and would contact me by 1:00pm.  Again he said he would note the case, leave a note for the engineer on his desk and would ask him directly to contact me.  I never received another call from the engineer.

After sending off an email to the sales rep and the support manager I was finally able to get someone’s attention and later the following day a new engineer was assigned to my case.

This instance has damaged my faith in Astaro support. I’m not sure if this has anything to do with Sophos aquiring Astaro, but it sure seems like since then the support has plummeted.

I’ll continue to use Astaro for my existing projects, however the next new project that comes along will have me looking for a competing device to try.

User unable to login to Astaro User Portal

I recently setup some of the lab staff for access to their remote database through an SSL VPN using the awesome Astaro Security Gateway.

One of the users was having some problems to login to the user portal though to change their password. It turns out I gave them them wrong password initially, but even with this correct password they still weren’t able to login.

I entered the WebAdmin and checked the Logging & Reporting -> View Log Files -> User authentication daemon log. I could see the users attempts to login, shown as:

2011:09:29-13:19:48 secure aua[5336]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="x.x.x.x" user="smithjohn" caller="portal" reason="Too many failures from client IP, still blocked for 363 seconds"

I hadn’t seen this before. This is a really good thing to prevent brute force or automated attacks at guessing the users password. However in this case we didn’t want to wait the 6 1/2 minutes to try again.

Under the Management -> WebAdmin Settings -> Security I temporarily changed the values that block the authentication to:

 
After 30 attempts
block access for 3 seconds

The user was then able to login to the user portal, change their password and logout. I then changed the values back to the following:

 
After 3 attempts
block access for 300 seconds

Hosting vsftpd (FTPS) server behind Astaro Security Gateway

At work we're moving from an internal Microsoft Windows hardware file server to a Ubuntu 10.04 LTS virtual server housed within the University data center. To provide secure, remote access to our shared files I've setup a vsftpd 2.2.2 FTP server that requires SSL for login and data transfer. This server lives "behind" an Astaro Security Gateway for protection.

I had some trouble with the setup of this initially, namely I could make a connection from outside on port 21, however I wasn't able to setup the data connection successfully to list the directory and perform transfers.

After much searching peppered with plenty of trial and error I was able to finally configure this setup correctly. Here is how I did it.

Server setup

• Ubuntu 10.04 LTS server
• vsftpd 2.2.2
• Self-signed SSL certificate

Generate a 5 year self-signed certificate using 2048 bits

sudo openssl req -x509 -nodes -days 1825 -newkey rsa:2048 -keyout /etc/ssl/certs/vsftpd.pem -out /etc/ssl/certs/vsftpd.pem

Install the vsftpd server if you haven’t already

sudo apt-get install vsftpd

Configure the vsftpd server configuration file

sudo nano /etc/vsftpd.conf

Here we need to add the following lines at the end of the configuration file. Note that a key here is you define what your FTP PASV ports will be for data transfers. I’m using random values, so please select your own instead of just copying these:

    rsa_cert_file=/etc/ssl/certs/vsftpd.pem
    ssl_enable=YES
    force_local_logins_ssl=YES
    force_local_data_ssl=YES
    ssl_tlsv1=YES
    ssl_sslv2=NO
    ssl_sslv3=NO
    pasv_min_port=33423
    pasv_max_port=33500

Save the configuration file, then restart the vsftpd service

sudo /etc/init.d/vsftpd restart

Astaro Security Gateway v8.103 setup

In this example we’ll pretend the Astaro Security Gateway external interface has an IP of 1.1.1.1 and an additional IP address of 1.1.1.2 configured for just the traffic to go to the FTP server. You would configure the additional IP address for the external interface by going to:

• Interfaces & Routing
• Interfaces
• Additional Addresses
• New additional address…
• Name = 1.1.1.2
• On interface = External (WAN)
• IPv4 Address = 1.1.1.2
• Netmask = 255.0.0.0
• Comment = my ftp server address
• Save and make sure to enable the IP address by clicking on the green light to the left of the adapter graphic

Next we need to define a new service on the Astaro. This will be used to tell it what ports to expect the data connections on. We’ll be using the port range we specified earlier in the vsftpd.conf file. To setup this service, do the following:

• Definitions
• Services
• New service definition…
• Name = FTP-Data
• Type of Definition = TCP
• Destination port = 33423:33500
• Source port = 1:65535
• Comment = File Transfer Protocol Data
• Save

OK, now we need to setup a definition for your internal FTP server that we’ll be exposing to the Internet. To do this, do the following:

• Definitions
• Networks
• New network definition…
• Name = ftp-server
• Type = host
• Interface = internal
• IPv4 Address = 192.168.0.22
• Comment = my internal ftp server
• Save

Now that we’ve configured the system and service defintions we’ll actually create the rules to allow the inbound connections to the external IP address (1.1.1.2) to be passed to the internal IP address (192.168.0.22) using the FTP port (21) and respond back and allow data connections using the range we specified (33423 to 33500).

First we setup the destination NAT rule (DNAT) by doing the following:

• Network Security
• NAT
• DNAT/SNAT
• New NAT rule…
• Traffic source = Any
• Traffic service = FTP
• Traffic destination = 1.1.1.2
• NAT mode = DNAT (Destination)
• Destination = ftp-server
• Destination service = FTP
• Save
• New NAT rule…
• Traffic source = Any
• Traffic service = FTP-Data
• Traffic destination = 1.1.1.2
• NAT mode = DNAT (Destination)
• Destination = ftp-server
• Destination service = FTP-Data
• Save

Make sure to enable both of these DNAT rules by clicking on the green light to the left of the DNAT rule number!

Lastly we’ll configure the packet filter rules to allow the traffic by doing the following:

• Network Security
• Packet Filter
• New rule…
• Source = Any
• Service = FTP
• Destination = ftp-server
• Action = Allow
• Save
• New rule…
• Source = Any
• Service = FTP-Data
• Destination = ftp-server
• Action = Allow
• Save

Again, make sure to enable both of these packet filter rules by clicking on the green light to the left of the packet filter rule number!

Client setup

On the two Mac systems we’re using the excellent Panic Transmit application. This allows us to access the share like a regular FTP server or mount the FTP server as a drive on the Mac (this is key for us). Create a new connection with the following parameters:

• Protocol = FTP with TLS/SSL
• Server = 1.1.1.2
• User Name = whatever your Linux login account is
• Password = whatever your Linux login password is
• Port = 21
• Use passive model = checked
• Save

On the ten Windows systems we’re using NetDrive which allows us to mount the FTP server as a drive in Windows explorer (again, this is key for my users). Create a new connection with the following parameters:

• Site name = 1.1.1.2
• Site IP or URL = 1.1.1.2
• Port = 21
• Server Type = FTP
• Drive = F
• Account = whatever your Linux login account is
• Password = whatever your Linux login password is
• Save
• Advanced
• SSL = Force SSL for all communications
• OK

Conclusion

That should have you setup and running now, able to access your internally hosted vsftpd server over SSL from external clients through the Astaro Security Gateway you have in front of the internal FTP server.

Reset forgotten Astaro WebAdmin 'admin' user password

I recently found myself in quite a predicate.  Although I'm extremely methodic in recording all of my passwords in my password manager Wallet, somehow I missed or incorrectly entered the one for one of my Astaro WebAdmin 'admin' user logins.  To further complicate the problem, I hadn't enabled the 'root' or 'loginuser' accounts for remote SSH access or set passwords for either, as this was a new install.  I was pretty sure I'd have to do a reload and install of the system, but it turns out I didn't.  Here is how I was able to reset the user accounts that I had forgotten and not set and recover.

1. Shutdown the firewall an connect a screen and keyboard, or in my case open the VMWare client console 
2. Recycle the power to the unit and wait for the GRUB-loader screen and press the "ESC" key 
3. Select the "Astaro Security Gateway x.x" version, NOT the previous or rescue option! 
4. Press the "e" key to edit that entry 
5. Move down to the second line, then press "e" to edit the line 
6. At the end of the line enter init=/bin/bash, no quotes 
7. Press the "Enter" key, then press the "b" key to boot the device/VM 
8. You can now change the root and loginuser account passwords by typing "passwd root" or "passwd loginuser" 
9. Restart the device and allow it to boot normally. 
10. When the system finishes booting, login as the root user 
11. To reset the Webadmin admin password, type "cc", no quotes, and press Enter 
12. Type RAW and press enter 
13. Type system_password_reset and press enter 
14. Browse to your WebAdmin login page (i.e. https://192.168.0.1:4444) and you should be prompted to create a new password for the admin account.