topic Access between several vlan in Network Security

Access between several vlan

Mikael Sveden — Tue, 12 Mar 2019 01:14:33 GMT

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

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 10:16:45 GMT

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

Access between several vlan

Mikael Sveden — Fri, 15 Mar 2013 10:59:05 GMT

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

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 11:11:16 GMT

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

Access between several vlan

Mikael Sveden — Fri, 15 Mar 2013 12:50:48 GMT

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

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 13:02:27 GMT

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

Access between several vlan

Mikael Sveden — Fri, 15 Mar 2013 13:32:01 GMT

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

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 13:40:59 GMT

Hi,

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

- Jouni

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 13:42:39 GMT

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

Access between several vlan

Mikael Sveden — Fri, 15 Mar 2013 13:45:41 GMT

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

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 13:52:02 GMT

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

Access between several vlan

Mikael Sveden — Fri, 15 Mar 2013 14:09:35 GMT

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)

Mar 15 2013

15:06:01

110003

192.168.10.1

192.168.13.13

Routing failed to locate next hop for icmp from NP Identity Ifc:192.168.10.1/0 to dmz:srv003/0

Access between several vlan

Jouni Forss — Fri, 15 Mar 2013 14:58:34 GMT

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

Access between several vlan

Mikael Sveden — Fri, 15 Mar 2013 23:10:38 GMT

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