OuttaCyTE
asked on
cisco pix vpn route issue - multiple subnets
Hi Experts,
I've got a problem that I'm trying to work out and I'm stuck.
I have a working VPN tunnel between Office A and Office B.
Office A-net is x.x.30.0/24 and Office B-net is x.x.31.0/24
At both offices, there is an out-of-band set of addresses for remote access to the hardware that I'd like to have transit over the VPN tunnel as well. These are on the same physical devices and there is no vlan in operation.
These are A-net-oob = x.x.32.0/24 and B-net-oob = x.x.33.0/24.
Currently I'm trying to get A-net to speak to B-net-oob over the VPN tunnel (remember A-net speaks to B-net just fine). I can ping the out-of-band addresses inside the same segment so I know that it will respond if it gets a request.
Office PIX-A:
! Don't NAT these
access-list inside_outbound_nat0_acl permit ip A-net 255.255.255.0 B-net 255.255.255.0
access-list inside_outbound_nat0_acl permit ip A-net 255.255.255.0 B-net-oob 255.255.255.0
! These are going from here to Office B
access-list outside_cryptomap_20 permit ip A-net 255.255.255.0 B-net 255.255.255.0
access-list outside_cryptomap_20 permit ip A-net 255.255.255.0 B-net-oob 255.255.255.0
! Showing I'm using the "outside_cryptomap_20" ACL for selection
crypto map outside_map 20 match address outside_cryptomap_20
Office PIX-B:
! Don't NAT these
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
! These are going from here to Office A
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
! Showing I'm using the "outside_cryptomap_20" ACL for selection
crypto map outside_map 20 match address outside_cryptomap_20
I can turn on debug icmp trace on both PIXes and when I ping an address from A-net to B-net I can see the trace on both PIXes. However, when I ping from A-net to B-net-oob I only see the Ping-request on PIX-A and not on PIX-B. No responses at all. Traffic for B-net-oob does not appear to be going over to PIX-B.
Of Note: If the Crypto map statement for B-net-oob is removed from PIX-A, then I get a traceroute that goes off into the internet someplace and gets lost (appropriately, it's not supposed to be routeable). When I put the statement back in, I get solid timeouts. This means to me that the Crypto map is capturing the traffic to send over the VPN, but it's failing or not going or some-such-thing. I can't see anything beyond what the icmp trace showed even if I turn on the most liberal packet tracing. The debug crypto statements don't show much at all (other traffic makes it tough to determine that it's nothing, but I don't see anything that I can identify).
I'm hoping you experts can help me through this thing. I need to be able to access the Office B out-of-band addresses from Office A (and vice-versa).
-greg
I've got a problem that I'm trying to work out and I'm stuck.
I have a working VPN tunnel between Office A and Office B.
Office A-net is x.x.30.0/24 and Office B-net is x.x.31.0/24
At both offices, there is an out-of-band set of addresses for remote access to the hardware that I'd like to have transit over the VPN tunnel as well. These are on the same physical devices and there is no vlan in operation.
These are A-net-oob = x.x.32.0/24 and B-net-oob = x.x.33.0/24.
Currently I'm trying to get A-net to speak to B-net-oob over the VPN tunnel (remember A-net speaks to B-net just fine). I can ping the out-of-band addresses inside the same segment so I know that it will respond if it gets a request.
Office PIX-A:
! Don't NAT these
access-list inside_outbound_nat0_acl permit ip A-net 255.255.255.0 B-net 255.255.255.0
access-list inside_outbound_nat0_acl permit ip A-net 255.255.255.0 B-net-oob 255.255.255.0
! These are going from here to Office B
access-list outside_cryptomap_20 permit ip A-net 255.255.255.0 B-net 255.255.255.0
access-list outside_cryptomap_20 permit ip A-net 255.255.255.0 B-net-oob 255.255.255.0
! Showing I'm using the "outside_cryptomap_20" ACL for selection
crypto map outside_map 20 match address outside_cryptomap_20
Office PIX-B:
! Don't NAT these
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
! These are going from here to Office A
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
! Showing I'm using the "outside_cryptomap_20" ACL for selection
crypto map outside_map 20 match address outside_cryptomap_20
I can turn on debug icmp trace on both PIXes and when I ping an address from A-net to B-net I can see the trace on both PIXes. However, when I ping from A-net to B-net-oob I only see the Ping-request on PIX-A and not on PIX-B. No responses at all. Traffic for B-net-oob does not appear to be going over to PIX-B.
Of Note: If the Crypto map statement for B-net-oob is removed from PIX-A, then I get a traceroute that goes off into the internet someplace and gets lost (appropriately, it's not supposed to be routeable). When I put the statement back in, I get solid timeouts. This means to me that the Crypto map is capturing the traffic to send over the VPN, but it's failing or not going or some-such-thing. I can't see anything beyond what the icmp trace showed even if I turn on the most liberal packet tracing. The debug crypto statements don't show much at all (other traffic makes it tough to determine that it's nothing, but I don't see anything that I can identify).
I'm hoping you experts can help me through this thing. I need to be able to access the Office B out-of-band addresses from Office A (and vice-versa).
-greg
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi again,
I looked at this again and think I spotted the mistake that jmeggers was trying to get at.
In the Office B setup:
! Don't NAT these
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
I don't have B-net-oob to A-net for NoNat, and in:
! These are going from here to Office A
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
I don't have the B-net-oob to A-net for routing.
jmegger's updates include these (and more)
I will give these a try when I get a chance either late at night or the weekend (as I can't afford to kill the client during the day with a typo...).
Thanks,
-greg
I looked at this again and think I spotted the mistake that jmeggers was trying to get at.
In the Office B setup:
! Don't NAT these
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list inside_outbound_nat0_acl permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
I don't have B-net-oob to A-net for NoNat, and in:
! These are going from here to Office A
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net 255.255.255.0
access-list outside_cryptomap_20 permit ip B-net 255.255.255.0 A-net-oob 255.255.255.0
I don't have the B-net-oob to A-net for routing.
jmegger's updates include these (and more)
I will give these a try when I get a chance either late at night or the weekend (as I can't afford to kill the client during the day with a typo...).
Thanks,
-greg
ASKER
I can report improvement. I now see the ping request on Office PIX-B.
I suspect the rest of the problem is the lack of a secondary address on the inside of the pix. I seem to remember some cheats for that so I'm going to look into them. I can't believe the PIX doesn't support a secondary IP address.
-g
I suspect the rest of the problem is the lack of a secondary address on the inside of the pix. I seem to remember some cheats for that so I'm going to look into them. I can't believe the PIX doesn't support a secondary IP address.
-g
ASKER
Frump...
Vlan not supported at all in Pix 501, even at version 6.3. Can't use the vlan trick to convince the pix to take a secondary address.
I'm open to suggestions not involving new/replacement equipment.
Otherwise I'll close this with points to jmegger
-g
Vlan not supported at all in Pix 501, even at version 6.3. Can't use the vlan trick to convince the pix to take a secondary address.
I'm open to suggestions not involving new/replacement equipment.
Otherwise I'll close this with points to jmegger
-g
ASKER
Thank you for responding. The main answer is that the PIX/ASA firewalls don't have a secondary IP address, and the 501's in particular don't even have VLAN so you can 'Fake' a secondary IP.
I'm going to look at other vendors as I'm tired of Cisco almost-but-not-quite implementations and nickle-dime thinking when it comes to the very smallest of shops.
I'm going to look at other vendors as I'm tired of Cisco almost-but-not-quite implementations and nickle-dime thinking when it comes to the very smallest of shops.
ASKER
Thank you for your reply and my apologies for taking so long to get back. Been snowed under since I posted.
I'll give this a try but first a couple of questions
1) Since Office A-net to Office B-net tunnel works and does not have the "reverse" entries you are suggesting, why should adding these reverse entries help for Office A-net to Office B-net-oob ?
2) I was holding off expanding any other direction (such as B-net-oob to A-net) until I got the first working to minimize the number of changes to be made. Is there some specific reason that I should put in all of them at once?
I really only get to play on this on the weekend.
-greg