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

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

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.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

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?

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

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

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.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

Jon,

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

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

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