Buy or Renew
Buy or Renew
NEW! Stay up-to-date on Cisco Secure Access: Software Release Notes and Announcements
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
861
Views
0
Helpful
13
Replies

Access between several vlan

Mikael Sveden
Level 1
Level 1

‎03-15-2013 03:05 AM - edited ‎03-11-2019 06:14 PM

I have problems with NAT several vlans.

I have specify nat from any to outside and I'm able to "get out":

object network any-out

nat (any,outside) dynamic interface

However I don't have any other access between vlan configured on my firewall. Can anyone please help me with how the other NAT configuration should look like? I would also like to have access from outside to server on DMZ network.

See my config in attached document.

Regards Mikael

Labels:
15356464-running.txt.zip
0 Helpful
13 Replies 13

Jouni Forss
VIP Alumni
VIP Alumni

‎03-15-2013 03:16 AM

Hi,

Traffic between your internal interfaces wont need any NAT if you dont specifically want to NAT something.

Traffic passing between 2 interfaces depends on

  • The "security-level" of the interfaces if NO ACLs are configured
  • The ACL if one is attached to the interface

The basic Static NAT configuration for a server would be

  • Only use if you have a spare public IP address for this server

object network SERVER

host x.x.x.x

nat (dmz,outside) static y.y.y.y dns

access-list permit any object SERVER eq

Where

  • SERVER = Name given to the object
  • x.x.x.x = Local IP address of server
  • y.y.y.y = Spare public IP address for the server
  • = The ACL you have attached to "outside" interface

The basic Static PAT (Port Forward) configuration for a server would be

  • Use if you only have the "outside" interface public IP address

object network SERVER-TCP80

host x.x.x.x

nat (dmz,outside) static interface service tcp

access-list permit tcp any object SERVER-TCP80 eq 80

Where

  • SERVER = Name given to the object
  • x.x.x.x = Local IP address of server
  • interface = Specifies that the "outside" interface IP address will be used
  • = The ACL you have attached to "outside" interface

- Jouni

0 Helpful

Mikael Sveden
Level 1
Level 1
In response to Jouni Forss

‎03-15-2013 03:59 AM

Hi jouni and thanks for quick answer!

How can it be that it doesn't work then when I have allowed from client net; any to any on port tcp,udp,icmp? See my access-list in previous attached post.

Regards Mikael

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to Mikael Sveden

‎03-15-2013 04:11 AM

Hi,

Can you try some example connection that is not going through with the "packet-tracer" from the CLI of the ASA.

For example

packet-tracer input client

Then copy/paste the output here

One option is also watch the ASDM realtime logs when attempting the connections and see what happens.

- Jouni

0 Helpful

Mikael Sveden
Level 1
Level 1
In response to Jouni Forss

‎03-15-2013 05:50 AM

This was strange. The packet-tracer finish successful but I still can't get it to work for my clients and the log shows "Teardown TCP connection".

firewall01# packet-tracer input client tcp 192.168.13.101 12345 192.168.10.14 443

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.10.0    255.255.255.0   dmz

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 13951, packet dispatched to next module

Result:

input-interface: client

input-status: up

input-line-status: up

output-interface: dmz

output-status: up

output-line-status: up

Action: allow

6    Mar 15 2013    13:44:53    302013    192.168.13.101    12345    192.168.10.14    443    Built outbound TCP connection 13956 for dmz:192.168.10.14/443 (192.168.10.14/443) to client:192.168.13.101/12345 (192.168.13.101/12345)

6    Mar 15 2013    13:44:53    302014    192.168.10.14    443    192.168.13.101    12345    Teardown TCP connection 13956 for dmz:192.168.10.14/443 to client:192.168.13.101/12345 duration 0:00:00 bytes 0 Free the flow created as result of packet injection

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to Mikael Sveden

‎03-15-2013 06:02 AM

Hi,

The log output is the result of the "packet-tracer" command as we can see from the ports and the Teardown message.

What we would need to see next is the log messages from an actual connection attempt from a host on behind "client" and heading to "dmz"

Notice that the Built and Teardown messages are normal messages you always see. Teardown therefore doesnt mean anything bad on its own. The reason of the Teardown is the thing we are looking for.

A normal TCP connection is torn down with the TCP FINs. If the destination doesnt answer (for any reason) to the connection attempt the message is SYN Timeout. If there is perhaps some problems with the connection there might be TCP RST etc.

- Jouni

0 Helpful

Mikael Sveden
Level 1
Level 1
In response to Jouni Forss

‎03-15-2013 06:32 AM

And here is the SYN Timeout...

6|Mar 15 2013|14:27:45|302014|srv004|443|192.168.13.101|55749|Teardown TCP connection 15447 for dmz:srv004/443 to client:192.168.13.101/55749 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:41|302014|srv004|443|192.168.13.101|55747|Teardown TCP connection 15443 for dmz:srv004/443 to client:192.168.13.101/55747 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:41|302014|srv004|443|192.168.13.101|55746|Teardown TCP connection 15442 for dmz:srv004/443 to client:192.168.13.101/55746 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:32|302013|192.168.13.101|55751|srv004|443|Built outbound TCP connection 15452 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55751 (192.168.13.101/55751)

6|Mar 15 2013|14:27:32|302013|192.168.13.101|55750|srv004|443|Built outbound TCP connection 15451 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55750 (192.168.13.101/55750)

6|Mar 15 2013|14:27:24|302014|srv004|443|192.168.13.101|55745|Teardown TCP connection 15441 for dmz:srv004/443 to client:192.168.13.101/55745 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:24|302014|srv004|443|192.168.13.101|55744|Teardown TCP connection 15440 for dmz:srv004/443 to client:192.168.13.101/55744 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:20|302014|srv004|443|192.168.13.101|55741|Teardown TCP connection 15439 for dmz:srv004/443 to client:192.168.13.101/55741 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:20|302014|srv004|443|192.168.13.101|55738|Teardown TCP connection 15438 for dmz:srv004/443 to client:192.168.13.101/55738 duration 0:00:30 bytes 0 SYN Timeout

6|Mar 15 2013|14:27:15|302013|192.168.13.101|55749|srv004|443|Built outbound TCP connection 15447 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55749 (192.168.13.101/55749)

6|Mar 15 2013|14:27:11|302013|192.168.13.101|55747|srv004|443|Built outbound TCP connection 15443 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55747 (192.168.13.101/55747)

6|Mar 15 2013|14:27:11|302013|192.168.13.101|55746|srv004|443|Built outbound TCP connection 15442 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55746 (192.168.13.101/55746)

6|Mar 15 2013|14:26:54|302013|192.168.13.101|55745|srv004|443|Built outbound TCP connection 15441 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55745 (192.168.13.101/55745)

6|Mar 15 2013|14:26:54|302013|192.168.13.101|55744|srv004|443|Built outbound TCP connection 15440 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55744 (192.168.13.101/55744)

6|Mar 15 2013|14:26:50|302013|192.168.13.101|55741|srv004|443|Built outbound TCP connection 15439 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55741 (192.168.13.101/55741)

6|Mar 15 2013|14:26:50|302013|192.168.13.101|55738|srv004|443|Built outbound TCP connection 15438 for dmz:srv004/443 (srv004/443) to client:192.168.13.101/55738 (192.168.13.101/55738)

It worked so good with my old PIX515 8.0(4). The config looked like this then:

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0

nat (dmz) 0 access-list client_nat0_outbound

nat (dmz) 1 0.0.0.0 0.0.0.0

nat (wlan) 0 access-list client_nat0_outbound

nat (wlan) 1 0.0.0.0 0.0.0.0

nat (server) 0 access-list client_nat0_outbound

nat (server) 1 0.0.0.0 0.0.0.0

nat (client) 0 access-list client_nat0_outbound

nat (client) 1 0.0.0.0 0.0.0.0

static (dmz,outside) tcp interface https srv004 https netmask 255.255.255.255

static (dmz,outside) tcp interface www srv004 www netmask 255.255.255.255

static (dmz,outside) tcp interface 3299 srv004 3299 netmask 255.255.255.255

static (dmz,outside) tcp interface ssh srv004 ssh netmask 255.255.255.255

static (dmz,client) 192.168.10.0 192.168.10.0 netmask 255.255.255.0

static (client,dmz) 192.168.13.0 192.168.13.0 netmask 255.255.255.0

static (wlan,client) 192.168.11.0 192.168.11.0 netmask 255.255.255.0

static (server,client) 192.168.12.0 192.168.12.0 netmask 255.255.255.0

static (client,server) 192.168.13.0 192.168.13.0 netmask 255.255.255.0

static (client,wlan) 192.168.13.0 192.168.13.0 netmask 255.255.255.0

static (dmz,wlan) 192.168.10.0 192.168.10.0 netmask 255.255.255.0

static (wlan,dmz) 192.168.11.0 192.168.11.0 netmask 255.255.255.0

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to Mikael Sveden

‎03-15-2013 06:40 AM

Hi,

Is there a specific reason you have changed every interfaces but the "outside" MTU to something other than the default 1500?

- Jouni

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to Jouni Forss

‎03-15-2013 06:42 AM

Generally the SYN Timeout tells us about the remote host that

  • Its not listening on the port
  • Local software firewall or similiar is blocking the connection
  • It has the wrong default gateway or traffic is otherwise forwarded in the wrong way
  • etc

- Jouni

0 Helpful

Mikael Sveden
Level 1
Level 1
In response to Jouni Forss

‎03-15-2013 06:45 AM

Yes, there is no vlan tag on outside interface but there is for all other interfaces.

I just tried to switch all to 1500 but it didn't make any different.

/Mikael

0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to Mikael Sveden

‎03-15-2013 06:52 AM

If you issue the command "show arp" can you see the DMZ server ARP?

Can you ping the server from the firewall?

Can you use the "ping tcp 443" from the firewall and see the SYN messages get a reply?

As the logs said, for some reason the server isnt replying to the connection forming. Or if it is its not sending that information to the firewall correctly.

- Jouni

0 Helpful

Mikael Sveden
Level 1
Level 1
In response to Jouni Forss

‎03-15-2013 07:09 AM

Strange that dmz is not showing in arp table:

firewall01# sh arp

        client 192.168.13.103 0027.22fa.36ed 1

        client srv001 001d.60da.7583 9

        client srv003 5404.a63c.631a 13

        client 192.168.13.101 0021.9bd4.49b5 34

        client 192.168.13.104 b499.baec.3e88 49

        client 192.168.13.5 b048.7a80.19ed 140

        outside 213.67.138.1 001b.0de4.81c0 11

I got  Routing failed when I ping from dmz interface to host on client interface:

firewall01# ping dmz 192.168.13.13

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to srv003, timeout is 2 seconds:

?????

Success rate is 0 percent (0/5)

6Mar 15 201315:06:01110003192.168.10.10192.168.13.130Routing failed to locate next hop for icmp from NP Identity Ifc:192.168.10.1/0 to dmz:srv003/0
0 Helpful

Jouni Forss
VIP Alumni
VIP Alumni
In response to Mikael Sveden

‎03-15-2013 07:58 AM

Hi,

That log message you see because you are trying to ping "client" host using the interface "dmz". Host 192.168.13.13 is not behind "dmz" interface

To ping a host just use

ping

To test connectivity to some server port use

ping tcp

If you cant see the ARP of the DMZ server or any DMZ host for that matter you should check network connections and the actual server for problems.

- Jouni

0 Helpful

Mikael Sveden
Level 1
Level 1
In response to Jouni Forss

‎03-15-2013 04:10 PM

Thanks for all help Jouni. I finally find the problem... it had to do with tag and untag vlan ports on the switch.

Regards Mikael

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card