cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
995
Views
0
Helpful
3
Replies

How to configure DMZ access for ftp/https without NAT

campbellpv
Level 1
Level 1

                 I have a closed network that is not connnected to the internet, just other sites that we want to communicate with.  We have a cisco router connected to the outside interface on an ASA5505 and a cisco router connected to the inside interface on the same ASA5505.  I have an inside interface that connects our management LAN, five separate DMZ interfaces with a separate LAN (VLAN) on each DMZ interface and the outside interface that connects to the other sites.  Data is not allowed to mingle between the five DMZ's. 

Alll connections to the other separate nodes are handled with the router on the external interface.  IPSEC GRE tunnels have been established between all sites and BGP routing has been verified.  Pings are good between inside, dmz and external interfaces and between the DMZ's and the other sites, to include hosts on our local networks and hosts at the remote sites.  Inter and intra traffic is enabled.

When a remote site attempts an https connection, the initial ACK handshake makes it through the ASA5505, but the return SYN/ACK is being knocked down and I don't understand why (it is not because of ACL's, they are any any at this point).

Looking for some ideas on why the return SYN/ACK to the remote site isn't getting through the ASA5505 outbound.  Will probably have the same issue with FTP, but right now, just trying to solve one problem at a time.

ASA5505 is in routed mode, not looking to NAT since the IP addresses in the DMZ need to be reached by their real IP address.

Thanks,

3 Replies 3

lcambron
Level 3
Level 3

Hello,

Sounds like routing issue, did you confirm the SYN,ACK is getting back to the ASA?

You can setup captures for this connection on the ASA to confirm this.

cap capin interface inside match tcp host source_IP host destination_IP

cap capout interface outside match tcp host source_IP host destination_IP

You can also configure asp captures to see if the ASA drops the packet:

cap asp type asp-drop all

show cap asp | inc source_IP

show cap asp | inc destination_IP

Have you looked at the logs related to this connection?

Regards,

Felipe.

When I use the packet-trace in both directions with the endpoint IP's, it works, all phases show allowed.   I see the hits against the ACL's that show the packet entry in to the outside interface of the ASA, the build up of the connection so the initial step of the external host ACK is reaching the webserver in the DMZ.  I see the hits against the incoming DMZ interface from the web server and then the log shows that the SYN,ACK is not in the state table and drops the outgoing packet.  Since no outgoing SYN/ACK, no three way handshake, not login prompt, no web page to the endpoint.

I even changed the security settings on the outside interface to match the DMZ, enabled the inter and intra connections and that didn't work.  ACL's on the incoming and outgoing outside and DMZ interfaces have any any tcp and any any ip but still the same result.

DMZ hosts point to the ASA.  ASA points to external router on the outside interface.  Pings all work fine.  Tried ACL's at the top with port 443, but no hits on that.  Even tried bypass with the same result.  The initial packet from the external host doesn't seem to enter the state table so that when the host sends the reply (SYN/ACK) the ASA knocks it down.

Also tried twice NAT with static source/destination/port so that what comes in should be what is sent to the DMZ.

If I understand this device, I should have a rule that lets traffic in the outside interface from the external networks, a rule that allows DMZ traffic out the outside interface, a rule that allows external traffic in the DMZ and a rule that allows DMZ internal traffic back out to the external interface.

Still fuzzy on exactly how the data goes between the outside and the DMZ interfaces. 

Is there something else I need to do or define to use HTTPS?  I see that HTTP is defined and also has inspection rules.

I can try the captures tomorrow at work.

Thanks, for any pointers you can provide me.

Peyton

This is my first, painful experience with the ASA. 

You actually only need to allow the traffic in the inbound direction on outside interface, the ASA does stateful inspection of the packet and allows the return traffic, so the connections only need to be allowed on the interface where the traffic is initiated, if you have any outbound ACL, that might be the problem.

I would suggest the captures so you can see where the packet is getting lost.

Regards,

Felipe.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: