VM-100 responding with SYNACK on all ports

[aisherwood]

Hey,

I've got an evaluation of the VM-100 (v7.0.2) setup, but I'm finding that for some reason the firewall appears to be intercepting requests and completing a TCP 3-way handshake, regardless if the ultimate destination has the port open or not. Has anyone got any idea if this is normal behaviour, or if I've miss-configured something somewhere (and if so, what specifically I need to do to undo it?)

Steps to replicate:
1. Configure VM-100 as follows:
NETWORK INTERFACES
Interface: ethernet1/1
Interface Type: Layer3

Virtual Router: default

Zone: trust
IP: 192.168.0.1/24

Interface: ethernet1/2
Interface Type: Layer3

Virtual Router: default

Zone: untrust
IP: 192.168.100.5/24

VIRTUAL ROUTERS

Name: default

Interfaces: ethernet1/1, ethernet1/2

Static Route

Name: default-route

Destination: 0.0.0.0/0

Interface: ethernet1/2

Next Hop: IP Address - 192.168.100.1

Metric: 10

NAT POLICIES
Source Zone: trust
Destination Zone: untrust
Destination Interface: ethernet1/2
Service: any
Source Address: any
Destination Address: any
Translation Type: Dynamic IP and Port
Address Type: Interface Address
Interface: ethernet1/2
IP address: 192.168.100.5/24

2. On the Internet (untrust zone) setup a webserver 'ServerA' and configure the host firewall to have TCP port 80 open, but all other ports (e.g. 1-79 and 81-65536) closed.

3. On the local network  (trust zone)  setup a Windows computer 'WorkstationB' perform a nmap 'Quick Scan' with a target of 'ServerA'

Expected Behavior:
nmap reports that port 80 is open, and all other ports closed/filtered.

Actual Behavior:
nmap reports that TCP ports 7, 9, 13, 21, 22, 23, 25, 25, 37, 53, 79, 80, 81, 88, 106, ... [cut]..., 49516, 49157 are all open.

The same thing happens if you attempt a nmap in the other direction  (e.g. run the scan on ServerA targeting the ethernet1/2 interface on the firewall - nmap returns all ports open, even though in reality only a couple of ports have a NAT rule configured to do destination address translation).

We've got a 7050 at work and it doesn't exhibit this behaviour (i.e. if the destination port is closed, there will be no SYNACK packet sent back to the source and the 3-way TCP handshake never completes). I'm not sure if this is because I've miss-configured something on the VM side, or because the virtual and hardware appliance functions differently.

All of this isn't a problem as such, the Internet still works just fine and servers in the trust zone accessed from untrust with a destination address NAT rule operate normally - it's just really confusing when I'm trying to troubleshoot problems and are not able to figure out if a destination address has a particular TCP port open.

Anyone got any thoughts?

[Raido_Rattameister]

If you put web server and nmap into same zone and same subnet and scan then do you see similar  behaviour (same ports send syn ack)?

If you configure security policy:

"from trust zone" to "untrust zone" and "application is web-browsing" and "port is any"

Then Palo allows web browsing on any port.

This means that TCP 3 way handshake (syn, syn-ack and ack) will be permitted by firewall, HTTP GET will be permitted by firewall and then based on server response firewall can decide if it is web browsing or not.

So you should create rule where instead of "service = any" you choose "application-default" or specify service by port number.

[aisherwood]

Hi Raido,

If I do a nmap of a webserver in the same zone and subnet then nmap returns 'normal' results (i.e. only the ports that are really open are reported as open, ports that are really closed are reported as closed.).  However, when I do this, traffic isn't flowing through the PA VM-100 (i.e. because it's in the same subnet it doesn't hit the default gateway - the firewall).

I had the same thought that it could have been caused from service=any rather than servce=application-default in one of the security rules.  In my security rules I did have a few instances of service=any.  For the purposes of troubleshooting I changed all those rules to application-default but the nmap scan kept saying all ports were open.

I also created a new security rule at the very top of the list with: source_zone=trust, dest_zone=untrust, dest_ip=serverA, application=any,service=application-default,action=allow,profile_type=none which I thought would override any problem security policies, but it didn't change the behavior, the nmap scan showed it still responding on all ports.

[Raido_Rattameister]

Do you have zone protection profile set with syn-cookies?

[Raido_Rattameister]

What you can do is to enable packet capture on firewall.

Log receive and transmit.

Check if those syn packets pass firewall (are received and transmitted) and if syn-ack is received from web server and transmitted further by fw.

[Raido_Rattameister]

Do you see anything in traffic log?

Application in those sessions should be "incomplete"

Click on magnifing glass and you see what rule permitted this traffic through.

[Anon1]

The IP address in the NAT policy has probably the wrong subnet mask: IP address: 192.168.100.5/24

You should use /32 here, not /24. The firewall is doing proxy arp for the whole subnet 192.168.100.0/24

[santonic]

It must be SYN cookie functionality.

[aisherwood]

I did have a zone protection profile set, but I've disabled it for troubleshooting purposes (and in any regards, syn-cookies didn't appear to be enabled in it). I've got no DoS Protection profiles either.

I tried running a packet capture and the results were interesting. When capturing on ethernet1/2 (untrust) I can see syn-ack packets from the target server in the packet capture which seems to suggest the server really is replying -- however, if I do the same nmap scan to a completely made up IP like 1.2.3.4 I also see syn-ack replies - so whilst they're in the captures, they can't be from the real source IP.

Traffic logs list the session as 'incomplete'.

In regards to the NAT policy, I had it configured the policy via the PA web GUI, and that IP was actually selected from a drop-down list of valid addresses and not me entering it directly (i.e. so I couldn't select /32 even if I wanted to). To simplify the rule I removed the IP address entirely so now it's just:

NAT POLICIES
Source Zone: trust
Destination Zone: untrust
Destination Interface: any
Service: any
Source Address: any
Destination Address: any
Translation Type: Dynamic IP and Port
Address Type: Interface Address
Interface: ethernet1/2
IP address: none

Is there anywhere else where syn-cookies could be configured that I've missed or got any other suggestions?