0

I did a test of NFS service over Cisco ASA 5505 firewall.

With normal interface default ACL, which is "permit ip any any" on inside interface (Level 100), "deny ip any any" on outside interface (level 0). NFS server is connected to outside interface. Everything works great. By look at the the packets go through, I can see inside PC call NFS server's 111 port, negotiate a port using portmap. Finished this TCP connection. Then NFS server (outside PC) use the negotiated port to connect to inside PC and transfers data. Cisco ASA firewall keep TCP states very well and "remembered" the negotiated port, thus let outside PC using this port to talk to inside PC even the outside ACL is "deny ip any any". The firewall is fully stateful, every thing is great so far.

However, as long as I connected the NFS server (outside PC) to Cisco ASA firewall using VPN. Everything changed. By look at the packets, NFS can still go through firewall and negotiate a port by portmap. While after this TCP session is over. Firewall FORGET the negotiated port and block the outside PC using negotiated port to talk back to inside PC.

With or without VPN is the only change. There is just one ACL, on inside interface, permit ip any any. The NFS server is set to can be access from any subnet. There is no NAT and no service-policies setup on this firewall.

Can anyone please explain why Cisco Firewall rules is not "stateful" anymore over VPN? Is it designed to be? What is the best way to let NFS working over VPN without open a range of dynamical ports on outside interface?

ricky1i
  • 11
  • 2

1 Answers1

-1

One of the strong sides on NFSv4.0 is firewall friendly. No port map required. You need only single TCP port 2049 to be opened. All operations which have have a state on the server require client to send a heard bit, which is typically ~ 90 seconds. We you is in your firewalled setup and quite happy with it.

kofemann
  • 4,217
  • 1
  • 34
  • 39