Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
New Member

ssh through Pix to 6500

I didnt really know how to describe the subject, so here goes.

Using a 6513 to originate SSH connection to a 6509 through a Pix 535.  that is what I'm attempting to do.

On Pix, 3 interfaces, outside sec level 0 192.168.15.11 /27,  inside sec level 100, 192.168.15.33 /24,  and a 3rd interface to be used for "mgmt" sec level 10, 10.10.10.1 /24.

On 6509, 2 physical interfaces 192.168.15.35 /24 and 10.10.10.2 /24.

from the 6513, I can ping to the 6509, thorugh the pix to both destinations.

However, from the 6513 I can only ssh to the 192.168.15.36 address.

I have noted, the following when pinging, using the sho conn on the pix

ping to 192.168.15.35

ICMP outside 192.168.15.10:152 Inside 192.168.15.35:0, idle 0:00:00, bytes 67608
ICMP outside 192.168.15.10:152 Inside 192.168.15.35:0, idle 0:00:00, bytes 67608

ping to 10.10.10.2

ICMP outside 192.168.15.10:153 Inside 10.10.10.2:0, idle 0:00:00, bytes 42336
ICMP outside 192.168.15.10:153 Jump_Mgmt 10.10.10.2:0, idle 0:00:00, bytes 42408

It appears the return traffic is coming back from the 6509 via the default route 0.0.0.0 0.0.0.0 192.168.15.33 RATHER than the connected route between the 2 10.10.10.0 /24 interfaces.  I see a TCP deny on the inside interface coming from the 6509 (10.10.10.2) which seems would make sense since the traffic didnt originate through the inside interface enroute to the 6509...

i'm not sure how to over come this...

any help would be appreciated...

bruce

2 ACCEPTED SOLUTIONS

Accepted Solutions
Cisco Employee

Re: ssh through Pix to 6500

Jon,

That is good thinking to do outside policy nat and force the source packets destined to 10.10.10.2 to look like the mgmt. interface so, the response will not have to do a route lookup.

I'd still do route-map.

(6513)192.168.15.35-----(192.168.15.33)-(i)PIX(o)-92.168.15.11----192.168.15.10(6509)

                                                                       |

                                                               10.10.10.1

                                                                mgmt(10)

                                                                        |

                                                             10.10.10.2

So you have

static (i,o) 192.168.15.35 192.168.15.35

and outside to inside ssh works fine

You also have

static(m,o) 10.10.10.2 10.10.10.2

but ssh from the outside to mgmt does not work?

Is the topology correct?

10.10.10.2 when responding back to 192.168.15.10 will do a route lookup for the destination and send the packet based on the default route to the inside interface. I believe that is what you are seeing? You can issue "sh ip cef 192.168.15.10" and see where it says it will send it.

access-list 120 permit ip h 10.10.10.2 h 192.168.15.10

route-map ROUTE-TEST permit 10
                match ip address 120
                set ip next-hop 10.10.10.1
interface
            ip policy route-map ROUTE-TEST

-KS


Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

i trust ya man...

the problem is this...

I have an access-group which is applied to the Outside interfaces using the "outside" acl...

I created the PNAT acl, associated it with the outside interface and it removed my existing access-group for the outside interface...

so, short of adding the following, i'm not sure how to apply what you are suggesting...

access-list Outside line 1 extended permit ip h 192.168.15.10 host 10.10.10.2

access-list Outside line 2 extended permit ip any any

access-list Outside line 3 extended permit icmp any any

access-group Outside in interface outside

Bruce

The PNAT acl does not need to be applied to an interface, it is simply for NAT. Leave your existing acl on the outside interface.

The only reference you need to the PNAT acl is in the nat statement itself. The PNAT acl is not concerned with permitting/restricting traffic.

Jon

36 REPLIES
Cisco Employee

Re: ssh through Pix to 6500

I didnt really know how to describe the subject, so here goes.

Next time if you give us a simple topology like this we can quickly understand what is going on.

topology:

(6513)192.168.15.35-----(192.168.15.33)-(i)PIX(o)-92.168.15.11----192.168.15.10(6509)

                                                                       |

                                                               10.10.10.1

                                                                mgmt(10)

                                                                        |

                                                             10.10.10.2 (6509)

Pls. tell us where you are trying to ping FROM and TO and what fails and what you see in the syslogs when ssh fails.

1. You need static translation for the inside 6509 to the outside - to initiate ssh session from the 6509

static (inside,outside) 192.168.15.35 192.168.15.35

2. permission

3. proper routing from the source to the destination through the firewall.

-KS

New Member

Re: ssh through Pix to 6500

thanks.

Pls. tell us where you are trying to ping FROM and TO and what fails and what you see in the syslogs when ssh fails.

      

         Ping works completely...from source 6513 ---> pix ---> 6509 10.10.10.2

                                            from source 6513 ---> pix ---> 6509 192.168.15.35

1. You need static translation for the inside 6509 to the outside - to initiate ssh session from the 6509

static (inside,outside) 192.168.15.35 192.168.15.35

         This works, completely, ping and ssh to 192.168.15.35

2. permission

      ssh allowed on all interfaces, acl allowing IP any any on all interfaces.

3. proper routing from the source to the destination through the firewall.

      connected routes between pix and 6509

what appears to be the problem is traffic gets initiated from the 6513, enters the pix on the outside interface, forwards the traffic via the "mgmt" interface to the 6509 ip 10.10.10.2.

however, the return traffic is entering the pix on the "inside" interface rather than the "mgmt" interface, and thus,the pix is dropping the traffic with a

"Deny TCP (no connection) from 10.10.10.2 on the interface Inside

this makes sense, because the traffic didnt get orginated at the inside, but rather than mgmt interface.  i'm not clear why the destination 6509 would send the traffic back via the default route (inside) rather than the connected route (mgmt)..????

bruce

Cisco Employee

Re: ssh through Pix to 6500

Looks like you need a route map.

match it to an acl and in there say if the source and destination for this ssh traffic and set the next hop at 10.10.10.1

Apply it on the inside facing interface on the switch side.

That should do it.

"Deny TCP (no connection) from 10.10.10.2 on the interface Inside

That message says that the response traffic from 10.10.10.2 going towards the source that initiated this flow is seen on the inside interface instead of the mgmt interface. So, route map and setting the next hop for the response traffic from 10.10.10.2 towards the source should work.

-KS

New Member

Re: ssh through Pix to 6500

i'm not familiar with the "route map"...i'll mess with it some...however, i'm not clear why this would be necessary...

if the static for the mgmt interace answers for 10.10.10.0 /24 for traffic entering the outside interface, sends it to the destination, why would the return traffic be directed to the inside interface when answering?

I thought the destination switch would first look to a connected route for the return traffic, no?

bruce

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

i'm not familiar with the "route map"...i'll mess with it some...however, i'm not clear why this would be necessary...

if the static for the mgmt interace answers for 10.10.10.0 /24 for traffic entering the outside interface, sends it to the destination, why would the return traffic be directed to the inside interface when answering?

I thought the destination switch would first look to a connected route for the return traffic, no?

bruce

Bruce

If i understand correctly when the packet goes to 10.10.10.2 the pix will indeed forward it out of the management interface because 10.10.10.2 is on a directly connected interface. However when the packet is sent back from the 6509 the destination packet will not be in the 10.10.10.x range, it will be whatever the original source IP was when you initiated the connection and that is why the default-route is used.

You could look at route-maps although because the traffic enters and leaves the same interface on the 6509 PBR might not work as expected. However another solution is simply to NAT the source IPs to the management interface as it sent on to the 6509. Then when the 6509 returns the packet the destination IP will be 10.10.10.1 ie. the pix management interface so it will arrive on the correct interface eg.

nat (outside) 1 192.168.5.0 255.255.255.240 outside

global (management) 1 interface

the above would nat any 192.168.5.1 -> 14 address to the IP address of the management interface as traffic goes from the outside to the management interface.

Jon

New Member

Re: ssh through Pix to 6500

that makes good sense...I realized the return traffic was coming back via the inside interface

because of the default route on the 6509, just wasnt sure how to get it back via the mgmt interface...

in my case, wouldnt it be something like this:

nat (outside) 1 192.168.15.10 255.255.255.255 outside

global (mgmt) 1 interface

hmmm...now that i look at that, what about traffic that's destination is 192.168.15.0 /28 as oppose to 10.10.10.0 /24?

wont this nat the 192.168.15.10 for all inbound traffic and route it on the pix via the mgmt interface?

Hall of Fame Super Blue

Re: ssh through Pix to 6500

Bruce

hmmm...now that i look at that, what about traffic that's destination is 192.168.15.0 /28 as oppose to 10.10.10.0 /24?

wont this nat the 192.168.15.10 for all inbound traffic and route it on the pix via the mgmt interface?

Yes, that thought occured to me as well after i had written the response. The answer is it would need testing. Thing is routing and NAT are separate functions. So the packet comes on the outside interface and there is a NAT statement. But unless the destination packet is routed via the management interface there will be no corresponding global statement. Obviously if you had a separate global statement with the the same id as the NAT on the inside interface then yes this could be a problem.

Now it defintely works that way on a router but can't remember for a pix. You could use policy NAT but again not sure if this works outside to inside ie.

access-list PNAT permit host 192.168.15.10 host 10.10.10.2

nat (outside) 1 access-list PNAT outside

global (mgmt) 1 interface

Both need testing - sorry but don't have access to a pix at the moment.

Jon

Cisco Employee

Re: ssh through Pix to 6500

Jon,

That is good thinking to do outside policy nat and force the source packets destined to 10.10.10.2 to look like the mgmt. interface so, the response will not have to do a route lookup.

I'd still do route-map.

(6513)192.168.15.35-----(192.168.15.33)-(i)PIX(o)-92.168.15.11----192.168.15.10(6509)

                                                                       |

                                                               10.10.10.1

                                                                mgmt(10)

                                                                        |

                                                             10.10.10.2

So you have

static (i,o) 192.168.15.35 192.168.15.35

and outside to inside ssh works fine

You also have

static(m,o) 10.10.10.2 10.10.10.2

but ssh from the outside to mgmt does not work?

Is the topology correct?

10.10.10.2 when responding back to 192.168.15.10 will do a route lookup for the destination and send the packet based on the default route to the inside interface. I believe that is what you are seeing? You can issue "sh ip cef 192.168.15.10" and see where it says it will send it.

access-list 120 permit ip h 10.10.10.2 h 192.168.15.10

route-map ROUTE-TEST permit 10
                match ip address 120
                set ip next-hop 10.10.10.1
interface
            ip policy route-map ROUTE-TEST

-KS


New Member

Re: ssh through Pix to 6500

yes, the scenario you describe is what is occurring....and the statics you show are correct except static (m,o) is for the entire subnet 10.10.10.0 /24 rather than just 10.10.10.2

sho ip cef 192.168.15.10 shows the next hop as the inside interface...

the config you outline, is that on the switch where ip 10.10.10.2 resides?  it appears so...

bruce

New Member

Re: ssh through Pix to 6500

access-list 120 permit ip h 10.10.10.2 h 192.168.15.10

route-map ROUTE-TEST permit 10
                match ip address 120
                set ip next-hop 10.10.10.1
interface
            ip policy route-map ROUTE-TEST

with this configuration, this will only affect traffic from 10.10.10.2, correct...

I still want traffic returning from the 6509, dest 192.168.15.35 to take the default route back through the inside interface...

thanks

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

access-list 120 permit ip h 10.10.10.2 h 192.168.15.10

route-map ROUTE-TEST permit 10
                match ip address 120
                set ip next-hop 10.10.10.1
interface
            ip policy route-map ROUTE-TEST

with this configuration, this will only affect traffic from 10.10.10.2, correct...

I still want traffic returning from the 6509, dest 192.168.15.35 to take the default route back through the inside interface...

thanks

Bruce

Is 10.10.10.2 a vlan interface on the 6500 ?

If so then yes Kusankar's config should only affect that traffic. However if 10.10.10.2 is a vlan interface then you need to modify the config supplied -

instead of "ip policy route-map ROUTE-TEST" you need "ip local policy route-map ROUTE-TEST".

This is because traffc generated by the router/L3 switch isn't normally policy routed even with a policy route-map applied to an interface. So you need to add the "local" keyword into the "ip policy route-map ...." statement.

Jon

New Member

Re: ssh through Pix to 6500

Jon,

there isnt a "local" option when i attempt to make that policy config on the interface..

Hall of Fame Super Blue

Re: ssh through Pix to 6500

Bruce

Apologies, the "ip local policy route-map .." command is not an interface command it is a global command so it applies to the entire switch.

I would be careful when applying this as i would with any global config. Don't forget that the other option is simply to try the policy NAT outside to inside on the pix.

Jon

New Member

Re: ssh through Pix to 6500

understood...but,I thought we had summized that global nat would apply to all traffic...dont want to do that...

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

understood...but,I thought we had summized that global nat would apply to all traffic...dont want to do that...

Not if you use policy NAT ie. you use an access-list to define when to NAT eg.

access-list PNAT permit host 192.168.x.x host 10.10.10.2

nat (outside) 1 access-list PNAT outside

global (mgmt) 1 interface

note the "outside" after the PNAT. That is the only thing i'm not sure about ie. whether you can have policy NAT and use the outside keyword as well.

So i guess you should be careful with either way

Jon

New Member

Re: ssh through Pix to 6500

roger..

thanks for your help on this...i'll give it a try and see if it works...

New Member

Re: ssh through Pix to 6500

let me make sure i got this correct.

create an access list PNAT (access-list PNAT permit host 192.168.15.10 host 10.10.10.2

nat (outside) 1 access-list PNAT outside

global (mgmt) 1 interface

what is actually natting the 192 to the 10.10???  is it that PNAT access list?

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

let me make sure i got this correct.

create an access list PNAT (access-list PNAT permit host 192.168.15.10 host 10.10.10.2

nat (outside) 1 access-list PNAT outside

global (mgmt) 1 interface

what is actually natting the 192 to the 10.10???  is it that PNAT access list?

Bruce

The access-list simply defines which traffic to NAT. So in this case when host 192.168.15.10 sends a packet to 10.10.10.2 192.168.5.10 will get natted to IP address assigned to the mgmt interface. To the 6509 the packet has a src address of 10.10.10.1 so it know to send it back to the pix management interface.

Jon

New Member

Re: ssh through Pix to 6500

ah...thats right...my bad...thanks

New Member

Re: ssh through Pix to 6500

no IP required in the access-list

ie.   access-list PNATline 1 ext permit IP h 192.168.15.10 h 10.10.10.2

???

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

no IP required in the access-list

ie.   access-list PNATline 1 ext permit IP h 192.168.15.10 h 10.10.10.2

???

that would be my bad

Yes you need an IP afer the permit

Jon

New Member

Re: ssh through Pix to 6500

lol...there is actually a "host" statement after permit also, thats why it was throwing me the curve...

thanks...

New Member

Re: ssh through Pix to 6500

hmmm...since i already have an access-list that allows IP any, it would seem i could use that (as it is applied to the outside interface)...

so, rather than access-list PNAT Outside blah blah,  i would just replace the "PNAT" acl with the existing "outside" acl...

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

hmmm...since i already have an access-list that allows IP any, it would seem i could use that (as it is applied to the outside interface)...

so, rather than access-list PNAT Outside blah blah,  i would just replace the "PNAT" acl with the existing "outside" acl...

Bruce

No you don't want to do that unless the only line in the acl is between the 192.168.15.10 host and the 10.10.10.2

Jon

New Member

Re: ssh through Pix to 6500

hmmm...that wont work...i'll have to add an ACE to the existing outside acl...

Hall of Fame Super Blue

Re: ssh through Pix to 6500

Trust me , just use a dedicated acl for the policy NAT.

New Member

Re: ssh through Pix to 6500

i trust ya man...

the problem is this...

I have an access-group which is applied to the Outside interfaces using the "outside" acl...

I created the PNAT acl, associated it with the outside interface and it removed my existing access-group for the outside interface...

so, short of adding the following, i'm not sure how to apply what you are suggesting...

access-list Outside line 1 extended permit ip h 192.168.15.10 host 10.10.10.2

access-list Outside line 2 extended permit ip any any

access-list Outside line 3 extended permit icmp any any

access-group Outside in interface outside

Hall of Fame Super Blue

Re: ssh through Pix to 6500

bruce.summers wrote:

i trust ya man...

the problem is this...

I have an access-group which is applied to the Outside interfaces using the "outside" acl...

I created the PNAT acl, associated it with the outside interface and it removed my existing access-group for the outside interface...

so, short of adding the following, i'm not sure how to apply what you are suggesting...

access-list Outside line 1 extended permit ip h 192.168.15.10 host 10.10.10.2

access-list Outside line 2 extended permit ip any any

access-list Outside line 3 extended permit icmp any any

access-group Outside in interface outside

Bruce

The PNAT acl does not need to be applied to an interface, it is simply for NAT. Leave your existing acl on the outside interface.

The only reference you need to the PNAT acl is in the nat statement itself. The PNAT acl is not concerned with permitting/restricting traffic.

Jon

New Member

Re: ssh through Pix to 6500

You're a genius!!!!

it worked....that is pretty awesome...

I could replace, in the acl, the "host 10.10.10.2" with the entire /24 subnet, i would think...

thanks

583
Views
0
Helpful
36
Replies
CreatePlease to create content