Richard A Breton

Port 25 through a web proxy

2010-03-02T07:53:00.003-05:00

Recently, a customer called complaining their email server was neither sending nor receiving email through the firewall. While looking through the firewall and NAT rules I noticed that incoming traffic destined for port 25 was being redirected to
port 25 on an internal host and that the firewall rules permitted this traffic. Examination of the change logs and ticketing system indicated the host to which port 25 was being directed to had been changed 24 hours earlier at the request of the customer.

Discussing the issue with the customer I realized the problem. The customer had recently purchased a web caching and proxy server that also scanned for virus and malware threats. He liked the way it performed so much, he thought he would configure his email to run through the device as well. After explaining to him how a proxy server works and what the limitations are he came to the realization that the device was not going to scan his incoming port 25 email traffic as he previously thought. I changed the NAT rule for port 25 to redirect directly to the mail server. He changed the mail server’s default gateway back to the IP address of the firewall and mail started flowing again.

Blocking Class A subnets...

2010-01-19T13:54:00.012-05:00

A client called in recently wondering why one of his customers was unable to establish an SSL VPN tunnel to their site. The client explained that they produce an applications that is specific to the medical field and is very multimedia intensive. So, they ship a server out to their customer locations so that the multimedia content can be served from the LAN at their location.
The server connects back to their headquarters using an SSL VPN tunnel to transfer data and get updates. Prior to shipping these servers out, they always test them to make sure all connectivity works.

This was the second server they shipped to their customer thinking that something was wrong with the first server. I started dumping for traffic on the external interface of the firewall with a filter for TCP port 443. The traffic was being dropped at the firewall. I looked at the firewall rules and saw that everything seemed to be in order. I did notice at the top of the list however, a large number of subnets that were being dropped. When I asked why those subnet were being dropped, they said because they were blocking all IPs that were being managed by the "RIPE Network Coordination Centre".

I did a whois for the IP address that was being dropped. Low and behold RIPE says that they manage the whole 151.0.0.0/8 subnet. A had to do a little checking for this because he told me his customer location was in California. Come to find out RIPE only manages 151.8.0.0 - 151.96.255.255. I moved the rule that drops 151.0.0.0/8 to right after the rules that were in place to allow TCP port 443 from the trusted clients in that range.

Strange Firewall Rule #1

2010-01-18T11:54:00.010-05:00

A few weeks ago a client called complaining that a new web application was not working. I asked my usual questions such as what is the internal IP address of the server and what is the external IP address they were testing from. I was told the IIS web server and Microsoft SQL server reside on the same device.

A quick check revealed that NAT translations were in place to translate 224.1.2.2<-->192.168.1.10. Firewall rules were in place to allow connectivity to TCP port 443 from particular IP's.

I asked the remote end to establish a session to the server in the normal way while I dumped for traffic with a filter for the internal IP. I saw traffic come in from the WAN interface, handshake with the server, and the server responded with web traffic. I asked them what the problem was and they told me that soon as the application needs to make a database call, it failed.

I wondered what could be wrong. Usually, when the web server and database server are on the same machine, there are no IP related connectivity issues. For giggles, I decided to dump on port 1443 to see if anything shows up on the internal interface.

Low and behold! The web application was making an outbound request to TCP port 1433 of the external IP of 224.1.2.2. Turns out the web application makes calls to the SQL server by using the FQDN (Fully Qualified Domain Name) of the machine. Their DNS server sits at another location and resolves to the external IP address of the server (The IP that resides on the external interface of the router).

Since the firewall DROPS traffic entering the external interface that is destined to TCP port 1443, it was being dropped. I had to add the following rule to get things to work:

Allow -p tcp -s 192.168.1.10 -d 192.168.1.10 --dport 1433

I informed them that for efficiency they may want to add the DNS name of the machine in the local HOST file so that the traffic is kept local to the machine. No word on that yet!