ACL issue with denied RFC spaces ?

jresnickehrlich · ‎11-18-2004

We have a secure web server (https://web.company.com) at HQ that is accessible from the Internet by public DNS and internally privately by Windows AD DNS. It is behind our 3725 router with IOS firewall. Firewall permits GRE and 1723 for Windows VPN purposes. The router has a static NAT mapping for it. Both public and private DNS records are correct and PTRs exist.

We added deny statements for RFC 1918, 3330 address spaces and our assigned block address spaces, as recommended per Cisco, to the 3725 router.

Before we added these statements, our remote branch office users (each office is on a 192.168.x.x network with a router doing NAT) could access the web server by name when they were VPN'd into HQ as well as when not VPN'd in. Now, they can only access the server by name if they are not VPN'd in. If they are VPN'd in and try https://web.company.com, they get error 404 Page not found. However, they can access it by private IP address.

They need to access the web server by name when VPN'd in because of company reasons. What do we need to do/edit in the ACL?

Thanks.

Joan Resnick Ehrlich

Richard Burts · ‎11-19-2004

If I understand your description correctly the users from remote site who are VPNed in can access the server by specific IP address but can can access it by name. The fact that they can access by address demonstrates that it is not a basic connectivity issue but point to difficulty with the inside DNS server. Can they access any resource where the name is resolved by the inside DNS?

If you could help us understand your topology, which interface the VPN traffic arrives on, where the VPN termination point is and which interface on the router, and where the DNS server is it might be helpful. Also if you post the output of show access-list it might help us understand what is happening.

HTH

Rick

HTH

Rick

jresnickehrlich · ‎11-23-2004

Thanks Rick. I tested before replying to you, as I was able to pinpoint that the issue started the same time I applied the ACL additions. I removed the ACL additions and the issue went away. So it is something in the ACL additions.

Here's our setup: 3725 Router between LAN and Internet. VWIC card with 2 serials. Traffic from/to Internet comes in/out both serials. CBAC. Same ACLs applied to both. ACL in allows 1723 and GRE for NT4 RAS VPN endpoint. ACL out allows almost all traffic out. NAT outside on serials, NAT inside on fasethernet connected to internal net.

Here’s the deny statements added to the top of the ACL applied in at serials:

remark deny special use address space per RFC 3330

deny ip 127.0.0.0 0.255.255.255 any

deny ip 192.0.2.0 0.0.0.255 any

deny ip 224.0.0.0 31.255.255.255 any

deny ip host 255.255.255.255 any

remark filter RFC 1918 address space

deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16.0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

remark deny companys public address space per RFC 2827

deny ip any

remark deny dns servers causing continuous invalid domain name packets

deny ip host 216.73.81.10 any

deny ip host 216.73.85.10 any

deny ip host 216.73.86.10 any

deny ip host 216.73.87.10 any

deny ip host 216.73.92.112 any

And the deny statements added to the top of the ACL applied out at serials:

remark Deny requests to dns servers

deny ip any host 216.73.81.10

deny ip any host 216.73.85.10

deny ip any host 216.73.86.10

deny ip any host 216.73.87.10

deny ip any host 216.73.92.112

No other changes to the ACL.

I need to note two things: With the above applied, everyone could still reach our Exchange 5.5 OWA server by name when VPN’d in. I thought that odd. The only differences are (1) the web server uses port 443, and (2) how it is set up in our private DNS. (Our ISP hosts our public DNS company.com). We have private W2K3 AD DNS us.company.com and use forwarders to resolve non-local. But our private DNS also hosts company.com for internal purposes. The web server has an A record in both zones, and two PTR records with same IP address, one for web.us.company.com and one for web.company.com so web.company.com can get resolved internally by private IP. The OWA server also has an A record in both zones, but only one PTR record, for owa.us.company.com.

And I just found out that one VPN user could reach the secure web server by name with the ACL additions applied. I think the difference is that the users who could not reach the web server by name are on their own local LAN on a 192.168.x.x subnet (the 3rd octet is different that our LAN) behind a router. Whereas the single VPN user is not.

Thanks,

Joan

Richard Burts · ‎11-23-2004

Joan

Thanks for the additional information. Is the VPN terminated on the 3725 or on something else?

My working theory at this point focuses on the line added to the access list of:

deny ip 192.168.0.0 0.0.255.255 any

Could you try the access list additions omitting this line?

HTH

Rick

HTH

Rick

jresnickehrlich · ‎11-23-2004

Hi Rick,

The 3725 passes thru VPN traffic via 1723 and gre. The VPN is MS Windows client (W2K, XP) to NT4.0 RAS. The 3725 is between the NT server and the Internet.

Just tested without the 192.168.0.0 line. Removing the line does not solve problem. I'm going to test next by adding back in one new section (denoted by remarks) at a time to the original ACL, then line by line of the section that causes the issue. Will let you know.

Thanks!

Joan

Richard Burts · ‎11-23-2004

Joan

Your approach to testing is very logical and should allow you to identify what is causing the problem.

I have thought more about this situation and have a couple of questions. Am I correct in understanding that without the access list addition users at remote sites could connect via VPN and could access the web server via name and via specific IP address. When the access list additions are in place the remote users connect via VPN can access the web server via specific IP address but can not access via name? Or have I misinterpreted the symptoms?

What is the relationship between the server that terminates VPN, the server that provides internal DNS, and the web server? Are they on the same subnet or different subnets?

Let me know what you find.

Rick

HTH

Rick

jresnickehrlich · ‎11-24-2004

Hi Rick,

Yes you are correct. Before additions, when VPN'd in, users at remote sites could access web.company.com by name and by private IP address 192.168.100.10. After additions, they could only access by private IP, not by name. (Actually, I should note that the remote user testing with me did not try accessing by public IP when VPN'd in, but in any case, name did not work and they need to access by name cause of special app)

Server that terminates VPN is NT4.0 BDC in our child AD Domain. Servers that host DNS are child domain DCs. Same subnet. Root domain is empty.

Here's what I found: deny RFC 1918 and deny the DNS servers sending invalid domain name packets worked ok. Left those in the ACL. Added RFC 3330 lines, got issue. Took out RFC 3330 and added deny our public IP blocks, also got issue. I was surprised both RFC 3330 and deny our public IP blocks caused the issue. I would think it would be one or other, since seems to me very different. Did not have time to test each line, just tested block of lines.

Anyway, as stands now, ACL applied has deny RFC 1918 statements and deny those DNS servers statements, and remote users can access web server by name when VPN'd in.

Will continue testing next week.

Have a good Holiday!

Joan