cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1690
Views
15
Helpful
19
Replies

Routing Logic mishap

fbeye
Level 4
Level 4

Hello.

 

I am having some routing issues and I know I am probably not seeing the obvious but here we go.

 

ASA-5508-X

   192.168.1.0

      inside DHCP (192.168.1.1-15)

   192.168.4.0

     server DHCP (192.168.4.177-181)

 

SB550X

   192.168.1.7 (vlan1)

         PBR to 192.168.5.1-15

   10.0.2.124 (vlan 2 (coming from different Router, unimportant))

         PBR to 192.168.16-32

 

The 192.168.4.0 is connecting to a L2 Switch so no routing needed. From that 192.168.4.x I have 192.168.4.180 which resolves back to an outside static IP x.x.x.180.

192.168.4.180 needs to PING 192.168.5.36 but can not seem to do so, and vice versa.

Their "common" connection is the ASA (192.168.4.0 (Subnet that .180 is on) and 192.168.1.0 (Subnet for the 192.168.5.0 via PBR on the SMB)).

On the ASA I have a static route;

inside192.168.5.0255.255.255.0192.168.1.71None

 

So I am unsure how to make 192.168.4.0 PING 192.168.5.0 (which translates through 192.168.1

19 Replies 19

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @fbeye ,

post show version of ASA 5508-X as NAT configuration has changed after 8.4

 

look for NAT hair pinning here in the forums likely Paul Driver has answered to similar questions.

 

Hope to help

Giuseppe

 

 

 

Cisco Adaptive Security Appliance Software Version 9.15(1)7
SSP Operating System Version 2.9(1.135)
Device Manager Version 7.5(1)

 

I did some searching on what you mentioned and that completely makes my brain melt. Completely above anything that even makes sense to me.

It's easier to just use the 2nd NIC in each device I have (I planned it this way) and create their own little LAN and forget the complexity!

 

What kills me is 192.168.5.0 is the Subnet (vlan 1) on SMB550X which has PBR (192.168.5.1-15) to 192.168.1.0 (via 192.168.1.7 IP on SMB) which goes to ASA and has PBR (192.168.5.16-32) to 10.0.2.0 (via 10.0.2.124 IP on SMB) which goes to Router and all that works fine but 192.168.4.179 (192.168.4.0 on ASA) can PING 192.168.5.1 but not the devices 192.168.5.2-32.

 

What I mean is, my Linux Server on 192.168.4.179 which connects to 192.168.4.1 on ASA can PING 192.168.5.1 (SMB550X) which is connected via PBR to 192.168.1.0 on ASA so clearly there is a route. ip routing is enabled so on and so forth. Just missing something!

A network diagram/topology drawing would be really helpful.

 

Not sure what PBR (policy based routing) is doing here exactly? Do you mean policy NAT? Or perhaps a combination of the 2?

Are you doing SNAT or DNAT? or both?

 

Anyway in my experience one common problem in this type of case, has been that the end hosts not knowing where to send the return traffic. (assuming the NAT is configured properly) 

 

It might be because they have multiple NICs or there might be multiple gateways on the subnet. 

When your Linux Server 192.168.1.179 pings 192.168.5.2, does the 192.168.5.2 server know where to send the return traffic?

Does (192.168.5.2) it see the traffic as coming from 192.168.1.179 or 192.168.4.179?

Check routing table/default gateway on the hosts.

 

Another possibility is that the local firewall on the server doesn't allow ping, at all or perhaps only from the local ip subnet.

Hello

Can yor post the following please
sh run object inline
sh run object group
sh run nat
sh nat detail
sh run access-list
sh run access-group
sh run policy-map | be glo
sh route | be Ga
sh interface ip brief

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

I have x'd out my real world IP's. if they are needed I can then post them to you.

I hope this gives you more detail.

Thank you

 

sh run object in-line
object network DLink host 192.168.4.178
object network mail host 192.168.4.180
object network inside subnet 192.168.1.0 255.255.255.0
object network ceyea host 192.168.4.179
object network 192.168.1.7 host 192.168.1.7
object network 192.168.5.0 subnet 192.168.5.0 255.255.255.0 description 192.168.5.0
object network HomeNetwork subnet 192.168.5.0 255.255.255.0
object network ServerDHCP host 192.168.4.1
object network 192.168.5.36 host 192.168.5.36

-------------------------

sh run object group
^
ERROR: % Invalid input detected at '^' marker.
 sh run object
object network DLink
host 192.168.4.178
object network mail
host 192.168.4.180
object network inside
subnet 192.168.1.0 255.255.255.0
object network ceyea
host 192.168.4.179
object network 192.168.1.7
host 192.168.1.7
object network 192.168.5.0
subnet 192.168.5.0 255.255.255.0
description 192.168.5.0
object network HomeNetwork
subnet 192.168.5.0 255.255.255.0
object network ServerDHCP
host 192.168.4.1
object network 192.168.5.36
host 192.168.5.36

------------------------

sh run nat
!
object network DLink
nat (Servers,outside) static x.x.x.178
object network mail
nat (Servers,outside) static x.x.x.180
object network inside
nat (inside,outside) dynamic interface
object network ceyea
nat (Servers,outside) static x.x.x.179
object network HomeNetwork
nat (any,outside) dynamic interface

--------------------

sh nat detail

Auto NAT Policies (Section 2)
1 (Servers) to (outside) source static DLink x.x.x.178
translate_hits = 5, untranslate_hits = 6482
Source - Origin: 192.168.4.178/32, Translated: x.x.x.178/32
2 (Servers) to (outside) source static ceyea x.x.x.179
translate_hits = 23, untranslate_hits = 9116
Source - Origin: 192.168.4.179/32, Translated: x.x.x.179/32
3 (Servers) to (outside) source static mail x.x.x.180
translate_hits = 42, untranslate_hits = 10209
Source - Origin: 192.168.4.180/32, Translated: x.x.x.180/32
4 (inside) to (outside) source dynamic inside interface
translate_hits = 0, untranslate_hits = 0
Source - Origin: 192.168.1.0/24, Translated: x.x.x.182/32
5 (any) to (outside) source dynamic HomeNetwork interface
translate_hits = 33099, untranslate_hits = 8731
Source - Origin: 192.168.5.0/24, Translated: x.x.x.182/32

-------------------

sh run access-list
access-list OUTSIDE extended permit tcp any object mail eq 993
access-list OUTSIDE extended permit tcp any object mail eq smtp inactive
access-list OUTSIDE extended permit tcp any object mail object-group sshmail
access-list OUTSIDE extended permit tcp any any eq 587

---------------------

sh run access-group
access-group OUTSIDE in interface outside

------------------

sh run policy-map | be glo
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect xdmcp
inspect snmp
policy-map type inspect dns migrated_dns_map_1
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
!

---------------------

sh route | be Ga
Gateway of last resort is x.x.x.182 to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via x.x.x.182, outside
[1/0] via 75.160.240.27, outside
C 192.168.1.0 255.255.255.0 is directly connected, inside
L 192.168.1.1 255.255.255.255 is directly connected, inside
C 192.168.4.0 255.255.255.0 is directly connected, Servers
L 192.168.4.1 255.255.255.255 is directly connected, Servers
S 192.168.5.0 255.255.255.0 [1/0] via 192.168.1.7, inside
S 192.168.5.36 255.255.255.255 [1/0] via 192.168.1.7, inside

-------------

sh interface ip brief
Interface IP-Address OK? Method Status Protocol
Virtual0 127.1.0.1 YES unset up up
GigabitEthernet1/1 x.x.x.182 YES CONFIG up up
GigabitEthernet1/2 192.168.1.1 YES CONFIG up up
GigabitEthernet1/3 unassigned YES unset administratively down down
GigabitEthernet1/4 unassigned YES unset administratively down down
GigabitEthernet1/5 unassigned YES unset administratively down down
GigabitEthernet1/6 unassigned YES unset administratively down down
GigabitEthernet1/7 192.168.4.1 YES CONFIG up up
GigabitEthernet1/8 unassigned YES unset administratively down down
Internal-Control1/1 127.0.1.1 YES unset up up
Internal-Data1/1 unassigned YES unset up down
Internal-Data1/2 unassigned YES unset down down
Internal-Data1/3 unassigned YES unset up up
Internal-Data1/4 169.254.1.1 YES unset up up
Management1/1 unassigned YES unset administratively down down

can you draw the topology here if you can ?

fbeye
Level 4
Level 4

Morning All

 

Alright so I have drawn my sketch and I hope it makes sense.

To reiterate, I want Server 192.168.4.179 to PING/Mount Samba Share from 192.168.5.36

I will state that everyone else on 192.168.5.x can Mount so it has permissions granted.

You mentioned PING goes both ways, as far as a response and so forth and I noticed I have one route (to) 192.168.5.0 through 192.168.1.7 but no Route to 192.168.4.0. I did this because I assume the 192.168.4.1 is already a known route as it is on the ASA but the 192.168.5.0 was not, as it was through 192.168.1.7 but it now occurs to me, how does 192.168.5.0 know 192.168.4.0 being it is somewhat "isolated" on the SB550X. I assume this means I indeed do need a route to 192.168.4.0 from the SB 192.168.5.0.

Anyway, here is the drawing.

Also, to be clear I do hae 2nd NIC's but none are active, at this point.

 

NEW.jpg

 

 


@fbeye wrote:

Morning All

 

Alright so I have drawn my sketch and I hope it makes sense.

To reiterate, I want Server 192.168.4.179 to PING/Mount Samba Share from 192.168.5.36

I will state that everyone else on 192.168.5.x can Mount so it has permissions granted.

You mentioned PING goes both ways, as far as a response and so forth and I noticed I have one route (to) 192.168.5.0 through 192.168.1.7 but no Route to 192.168.4.0. I did this because I assume the 192.168.4.1 is already a known route as it is on the ASA but the 192.168.5.0 was not, as it was through 192.168.1.7 but it now occurs to me, how does 192.168.5.0 know 192.168.4.0 being it is somewhat "isolated" on the SB550X. I assume this means I indeed do need a route to 192.168.4.0 from the SB 192.168.5.0.

Anyway, here is the drawing.

Also, to be clear I do hae 2nd NIC's but none are active, at this point.

 

NEW.jpg


I was scratching my head at this, but I think I might have found the problem.
From what I can see the NAS (192.168.5.36) is not included in the PBR.
From your network diagram it shows that only traffic from hosts 192.168.5.1-15 will be sent to the ASA. (and .16-.32 will go to the office WAN)

And there is no other route on the SG550?

If this is the case a route or added PBR on the SG550 to direct the traffic the right way should resolve the problem.

 

When you say that everyone else on 192.168.5.x can mount, do you mean locally on vlan1?

If there is there any communication working between the hosts on 192.168.4.x and the hosts on 192.168.5.x, it it only within the .1-15 range?

 

The other possibility I thought of was a problem with security levels between the inside and server interfaces. (and not allowing same security traffic if they have the same level)
Since the only ACL you seem to have is incoming on the outside interface. but from what I can see the traffic should go from the server interface
 to the inside interface.

I truly apologize for this but I made a mistake on my ol’ cut and paste. I was looking off of my Catalyst when I posted it but the rule is actually this ;

 

access-list 101 permit ip 192.168.5.0 0.0.0.31 any

access-list 102 permit ip 192.168.5.32 0.0.0.15 any

( in the above, my intentions are 15 IP’s for 101 and 15 IP’s 102, I hope that’s right)

So, 192.168.5.36 is indeed within the parameters of the PBR.

I also did verify I have;

same-security-traffic permit inter-interface


I apologize for my mistake

I truly apologize for this but I made a mistake on my ol’ cut and paste. I was looking off of my Catalyst when I posted it but the rule is actually this ;

 

access-list 101 permit ip 192.168.5.0 0.0.0.31 any

access-list 102 permit ip 192.168.5.32 0.0.0.15 any

( in the above, my intentions are 15 IP’s for 101 and 15 IP’s 102, I hope that’s right)

So, 192.168.5.36 is indeed within the parameters of the PBR.

I also did verify I have;

same-security-traffic permit inter-interface


I apologize for my mistake


@fbeye wrote:

I truly apologize for this but I made a mistake on my ol’ cut and paste. I was looking off of my Catalyst when I posted it but the rule is actually this ;

 

access-list 101 permit ip 192.168.5.0 0.0.0.31 any

access-list 102 permit ip 192.168.5.32 0.0.0.15 any

( in the above, my intentions are 15 IP’s for 101 and 15 IP’s 102, I hope that’s right)

So, 192.168.5.36 is indeed within the parameters of the PBR.

I also did verify I have;

same-security-traffic permit inter-interface


I apologize for my mistake


From this post 192.168.5.36 is matched in access list 102.
Isn't 102 for PBR traffic going to the offsite WAN? 
If so, the traffic will go the wrong way when trying to communicate with the 192.168.4.x hosts.

Also as Paul mentioned. 
From the network drawing the next hop address shown for the traffic is the SG550 itself, not the IP of the next node.
Is this a typo or the actual case?

Hello


@fbeye wrote:

192.168.4.180 needs to PING 192.168.5.36 but can not seem to do so, and vice versa.

access-list OUTSIDE extended permit tcp any object mail eq 993
access-list OUTSIDE extended permit tcp any object mail eq smtp inactive
access-list OUTSIDE extended permit tcp any object mail object-group sshmail
access-list OUTSIDE extended permit tcp any any eq 587

 

sh run access-group
access-group OUTSIDE in interface outside

 

sh run policy-map | be glo
policy-map global_policy
class inspection_default



You dont require any static route on the 5550 back towards the real network 192.168.4.x as that is the "hidden" network on the inside of the ASA and the 5550 has  directly connected interface in the natted "public"subnet.

 

It seems your missing a object-group sshmail thats being called by access-list OUTSIDE and for icmp-echo that return traffic isnt being allowed to enter by this access-list or by the global policy-map.


By default icmp is statless so its not subject to inspection by the asa, as such it needs to be allowed into the fw manually

 

Try the following to at least allow echo-reply to be allowed in by the ASA:
access-list OUTSIDE extended permit icmp any any eq echo-reply

 

or 
policy-map global_policy
class inspection_default
inspect icmp


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

fbeye
Level 4
Level 4

So I am thinking... My Linux Server can PING 192.168.5.1 (vlan 1 IP) on the SG550X but nothing inside... That tells me routing logic allows 192.168.4.0 to "see" 192.168.5.0 but I can not ping or access anything inside (192.168.5.36 more specifically.)

It occurred to me that I have no INCOMING ACL into the SG550X. Being ACL 102 is the PBR for 192.168.32-45 to access 10.0.2.124 (Intern), I assume I need to add an ACL for incoming (from 192.168.1.7 because 192.168.1.1 is on ASA along with 192.168.4.1) to allow anything from 192.168.1.7 to be able to access 192.168.32-45.

Am I over thinking this or is this simply an ACL issue, because 192.168.1.7 is L3 maybe it blocks everything by default?

Hello


@fbeye wrote:

So I am thinking... My Linux Server can PING 192.168.5.1 (vlan 1 IP) on the SG550X but nothing inside


You don't state where you linux server resides?
Also.

5550
-----
192.168.1.7 gig1/1
10.0.2.124 gig1/2
192.168.5.0 /24 vlan 1


192.168.5.1 - 15 netxhop 192.168.1.7 <asa> should be 192.168.1.1
192.168.5.16 - 32 netxhop 10.0.2.124 <office wan>  should be 10.0.2.x
192.168.5.36 

Regards access lists being applied to the 5550 then , this is the first time you have mentioned them being applied so yes having acls on a 5550 and then prohibiting access will cause you issues if they are not correct

Lastly don't forget 192.168.5.16 - 32 will not be able to respond to any traffic from the asa because you have it presumably routing via the office wan

If you could share the present routing config of the asa and the 5550 in a file and attach it to this post maybe we would be much clearer on you current setup is.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking products for a $25 gift card