Cannot Route Between Subinterfaces

[jimmlegs]

I am unable to route from my primary network to any sub-interfaces. I am attempting to segment the network and have created some /30 networks but I am unable to route to them. I have an ASA connected to a Meraki MS250-24P, my primary network is 192.168.68.0/24 and I have been unable to route to for example: 192.168.168.92/30 

!

interface GigabitEthernet1/2.68
vlan 68
nameif inside-68
security-level 100 ip address 192.168.68.253 255.255.255.0 standby 192.168.68.254
!

interface GigabitEthernet1/2.204
vlan 204
nameif network-d
security-level 55 ip address 192.168.168.93 255.255.255.252
!

Any help would be much appreciated.

Thanks

[Karsten Iwen]

Assuming that there is no access-list blocking the traffic, it should work.

How do you test it? If your test is to ping 192.168.168.93 from the primary network, then it can not work as that is not working on the ASA and Ping is by default not state fully inspected by the ASA. You have to test it with an internal PC and for ping, make sure to have ICMP-inspection enabled:

policy-map global_policy
 class inspection_default
  inspect icmp

And what is the output of packet tracer?

packet-tracer input inside-68 tcp 192.168.100 1234 192.168.168.94 80

[Richard Burts]

@Karsten Iwen makes an excellent point about enabling inspection for icmp. If that does not resolve the issue it would be helpful if you would post the running config (with disguises for any Public IP and passwords) so that we can see what else might be involved.

If that does resolve the issue then your /24 would be able to initiate traffic to the /30 (and receive responses) but given the security levels configured the /30 would not be able to initiate traffic to the /24. Is that an issue?

The standby address in the /24 indicates that this is a failover pair of ASA. I note that the /30 does not have a standby address (and indeed with an ASA and a single downstream device there is not room in the subnet for a standby address). Is that an issue?

[Georg Pauwen]

Hello,

since you have an active/standby setup, I guess it would be helpful to see a diagram of your topology, can you post that ?

[jimmlegs]

Thanks for the feedback all! I've attached a sanitized version of the conf to this post.

My model didn't appear to have a TCP option as provided by Karsten so I modified it to use echo, please let me know if I should try something else, this is the command I ran:  packet-tracer input inside-68 tcp 192.168.68.100 echo 192.168.168.94 echo.

Here are the packet-tracer results:

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop HostEx-inside4 using egress ifc segment-d

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_out in interface inside-68
access-list inside_access_out extended permit ip any4 any4
Additional Information:

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1395404, packet dispatched to next module

Result:
input-interface: inside-68
input-status: up
input-line-status: up
output-interface: segment-d
output-status: up
output-line-status: up
Action: allow

Good point about the failover IPs but at this point I need communication and can then look towards moving the appliances to a more robust /29 network.

Thank in advance all, I've inherited this configuration and am not as strong in networking as I am with other technology sets.

[Georg Pauwen]

Hello,

you have configured the physical interface with an IP address. That traffic is untaggged (equivalent to the native Vlan (1). What do you have physically connected to interface GigabitEthernet1/2, a trunk I assume, with the same native default Vlan (1) ?

interface GigabitEthernet1/2
description Inside-Interface
speed 1000
duplex full
nameif inside
security-level 100
ip address 192.168.168.65 255.255.255.240 standby 192.168.168.68
!

[jimmlegs]

Yes, it looks like it is connected to a trunk port with native VLAN 1

 

[jimmlegs]

Would removing the IP from the physical interface and replacing it with a subinterface fix the issue? Something like:

interface GigabitEthernet1/2
  no ip address 192.168.168.65 255.255.255.240 standby 192.168.168.68

interface GigabitEthernet1/2.168
  vlan 168
  nameif inside-168
  security-level 100
  ip address 192.168.168.65 255.255.255.240 standby 192.168.168.68

[Richard Burts]

Whether to leave the IP address on the physical interface or to move it to a subinterface depends on how the switch is configured. If the IP address you are attempting to access on the switch is in a vlan other than vlan 1 then yes you should move the ASA IP to a subinterface.

If the ASA has the IP on a physical interface then it would send the Ethernet frame with no tag (which would indicate that it was in the native vlan). In that case the switch would associate the frame with vlan 1 (or whatever is the native vlan on the trunk). If the switch IP is, in fact, in vlan 168 then the switch needs to receive a frame with tagging for vlan 168.

So how is the switch configured?

[jimmlegs]

The devices configured with 192.168.168 addressing are on Native VLAN 1 for some reason. These networks are all segmented so I am unsure if replacing the physical IP address with a subinterface would affect them. I do not see VLAN 168 configured on any switchports.

[Georg Pauwen]

Hello,

--> The devices configured with 192.168.168 addressing are on Native VLAN 1 for some reason.

If that is the case, the configuration is fine.

That said, it might help to at the least the trunk port configuration of the switch, can you post that (full config would be better)...

[jimmlegs]

Unfortunately no they are Meraki switches, the most I can do is post screenshots. It looks like the only things configured with the physical interface as their gateway's are the IPs on the Meraki's themselves. I am moving the Meraki IPs to another network to see if that takes care of the traffic on the interface. 

I've included an image of the IP Tables spreadsheet for the 192.168.168.0 address space. My issue is specifically getting any traffic from 192.168.68.0/24 to the 192.168.168.88/30, and 192.168.168.92/30 networks. These networks are on subinterfaces with VLAN IDs 203 and 204 respectively.

[jimmlegs]

I reverted the Meraki IPs back, some weird things started to happen with communication to the uplink.

[Richard Burts]

I am a bit confused. On the one hand you have told us "The devices configured with 192.168.168 addressing are on Native VLAN 1 for some reason." But then you tell us that you need to communicate with devices in vlan 203 and 204. Which statement is accurate?

In looking at the posted config I see a host address of 192.168.168.90 which is in vlan 203 and a host address of 192.168.168.94 which is in vlan 204. It looks to me like the ASA config is fine for accessing those addresses, ask long as the Meraki config does have those addresses in those particular vlans and does have the connection to the ASA as a trunk and the trunk does carry those vlans.

Can you verify those aspects of the Meraki config?

Can you post the content of the arp table from the ASA? Looking particularly to see if those addresses are in the table, but also looking to see if any addresses in the arp table are associated with subinterfaces.

[jimmlegs]

Sorry for the confusion, I am deconstructing this as we go along and am very appreciative of all of the help. The trunk connection between the ASA and the Meraki are configured with Native VLAN1, I was thinking perhaps this was interfering with communication to other VLANs.

I've grabbed most of the pertinent Meraki configuration and settings pages

sh arp
outside 149.97.188.5 f4cc.5582.c7c3 565
dmz1 server16 0050.56b6.488c 3
dmz1 server31 0050.56b6.0044 11
dmz1 server18 0050.56b6.7bf9 17
dmz1 server24 0050.56b6.1199 49
dmz1 server01 0050.56b6.b7f7 53
dmz1 server27 0050.56b6.4d94 54
dmz1 server25 0050.56b6.8474 88
dmz1 server21 0050.56b6.bef2 179
dmz1 server26 0050.56b6.912e 247
dmz1 server15 0050.56b6.1f65 261
dmz1 server30 0050.56b6.992d 271
dmz1 server04 0050.56b6.5e7e 297
dmz1 server17 0050.56b6.abb6 335
dmz1 server29 0050.56b6.66ee 406
dmz1 server28 0050.56b6.2fc8 441
dmz1 server23 0050.56b6.a03a 469
dmz1 server02 0050.56b6.91b0 518
dmz1 server22 0050.56b6.6089 529
dmz1 server19 0050.56b6.4e42 655
dmz1 server20 0050.56b6.2f8f 656
dmz1 server03 0050.56b6.96eb 824
inside 192.168.168.78 ac17.c8f6.3200 9
inside 192.168.168.68 700f.6a11.8685 1255
inside 192.168.168.71 ac17.c8f6.6a20 3444
inside 192.168.168.70 ac17.c8f6.6a20 3462
inside 192.168.168.77 ac17.c8f6.6a20 4830
inside-68 192.168.68.252 0018.0a4f.0001 12
inside-68 NY4-WIN-JUMPBOX 0050.56b6.2bc1 92
inside-68 192.168.68.33 d4f5.ef38.bf89 4633
inside-68 192.168.68.34 d4f5.ef38.c20b 5353
inside-68 192.168.68.55 000c.2946.da5f 5413
inside-68 ny4-vsyslog1 0050.56b6.a252 7033
inside-68 NY4-vNS1 0050.56b6.5b16 11983
inside-68 NY4-vNS2 0050.56b6.c396 12043
segment-a HostEx1 e4fc.8270.1f01 609
segment-b HostEx2 e4fc.8276.a0e5 446
folink 192.168.2.2 700f.6a11.868b 5268
segment-c HostEx3 cc7f.76a0.c08c 5443
segment-d HostEx4 bc5a.56c9.8ce4 5473