This is an interesting scenario to me. I really like this, and when I did this, I thought this was not going to be possible. I certainly learned something this day. Lets do a dual ISP redundancy thing, with MetroE and DSL as a backkup, plus a private LAN on the public network. Wow, this already sounds fishy, but its pretty cool. Ok, so here is how this thing works. Under normal operation, all the traffic goes out the MetroE (since its the more reliable network connection, plus more bandwidth). According to the diagram below, I have a 2911 Cisco router that has a Pix connected to Gig0/0 (which goes to the internal network of the customer), a 10Meg MetroE connected to Gig0/1, and a DSL modem connected to Gig0/2.
Notice these things:
1. Public IP on Gig 0/0 and Gig0/1
2. Private IP on Gig0/2 ---> What???
Ok, what doesn't make sense here? A private IP on a public network? Well, this customer wanted to be able to do two things:
1. Be able to have ISP fail over should the MetroE go down.
2. Use the DSL wireless and wired ports anytime they chose to for testing, guest wireless, etc.
Man, this customer really challenged me on this one (Thanks Ty!). At first, I told the customer that this couldnt be done. But, then the customer said something to me that made me really have to think about this: "I just thought someone as smart as you could make that work". Ok, challenge on. And no, Im not that smart, but thanks. So, here is what happens. As I stated earlier, under normal operation, all the traffic goes out the MetroE (unless you are tied to the DSL modem ports (you know how they have a built in switch and wireless)). So, Im happy going out the MetroE. I have a public IP address of the Pix interface when my packet goes out, and all is good.
Now, what happens when the MetroE goes down? Well, Cisco has this technology called "object tracking". Its pretty cool. The results are the same as a routing protocol (like BGP or OSPF) would do, however it operates differently. What happens is that the 2911 Cisco router is monitoring two destinations. See the below:
ip sla 1
icmp-echo 4.2.2.2 source-ip 77.77.77.94
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.1 source-interface GigabitEthernet0/2
frequency 5
ip sla schedule 2 life forever start-time now
ip route 4.2.2.1 255.255.255.255 10.0.0.1 permanent
ip route 4.2.2.2 255.255.255.255 77.77.77.93 permanent
Ok, above we have this: 4.2.2.2 is being tracked on interface 77.77.77.94 (Gig0/1). 4.2.2.1 is being tracked on interface Gig0/2. If you look at the "ip sla 1", every 5 seconds it sends out a ping to 4.2.2.2. It does this forever. If you look at the "ip sla 2", every 5 seconds it sends out a ping to 4.2.2.1. It does this forever. Both sla's are looking for a response from the two sites it sends to. Its tracking its "reachability". Oh, and the two static routes say that 4.2.2.1 ALWAYS goes out to 10.0.0.1 and 4.2.2.2 ALWAYS goes out to 77.77.77.93 (as far as packets destined for the two addresses).
Now, notice this entry:
track 10 ip sla 1 reachability
delay down 2 up 2
!
track 20 ip sla 2 reachability
delay down 2 up 2
This above says that "track 10" will be tracking the reachability of "ip sla 1" (4.2.2.2). "Track 20" will be tracking the reachability of "ip sla 2" (4.2.2.1). If one of the sites goes down after "2" failures of a ping response, do something (we will get to that "do something" in a minute). If the reachability is now accessable again after being down, and it can get to the destination "2" more times, "do something else" after the "2" times is reached. Ok, what happens is this. Look at the routing table:
ip route 0.0.0.0 0.0.0.0 77.77.77.93 track 10
ip route 0.0.0.0 0.0.0.0 10.0.0.1 5 track 20
ip route 4.2.2.1 255.255.255.255 10.0.0.1 permanent
ip route 4.2.2.2 255.255.255.255 77.77.77.93 permanent
Notice that there are two static routes that are permanent. These two, no matter what, always exist (because they are permanent). Its by design because of this object tracking feature. They reflect what we are tracking and out the interface we want them to go out. Now, the other two static routes say that the default route should go out two different interfaces. Notice that they say "track 10" and "track 20". Also notice that "ip route 0.0.0.0 0.0.0.0 10.0.0.1 5 track 20" has an AD of 5, not 1 like in the "ip route 0.0.0.0 0.0.0.0 77.77.77.93 track 10" statement. So, that means first that the default "default route" is the one with an AD of 1. Then the second default "default route" is the one with an AD of 5. (Man, this could be confusing.) In other words, use the first default route if available. "If available" meaning, if you can reach it in the "ip sla 1" command (if you can reach 4.2.2.2). If you cant, then failover to the second default route, which tracks 4.2.2.1 in "ip sla 2" (across the DSL). You see how this is going to work now as far as the tracking goes? Pretty cool. Now, if the MetroE is out, and traffic is being routed across the DSL, then you still have Internet traffic (you also have to be thinking about external DNS weights on your www servers, etc). When the MetroE comes back up, after two successful pings of the "ip sla 1" and "track 10" statements, the route is put back in.
Under normal operation, the routing table looks like this:
router#sh ip route
Gateway of last resort is 77.77.77.93 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 77.77.77.93
4.0.0.0/32 is subnetted, 2 subnets
S 4.2.2.1 [1/0] via 10.0.0.1
S 4.2.2.2 [1/0] via 77.77.77.93
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet0/2
L 10.0.0.2/32 is directly connected, GigabitEthernet0/2
69.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C 77.77.77.92/30 is directly connected, GigabitEthernet0/1
L 77.77.77.94/32 is directly connected, GigabitEthernet0/1
C 55.55.55.0/28 is directly connected, GigabitEthernet0/0
L 55.55.55.1/32 is directly connected, GigabitEthernet0/0
When the MetroE goes down, the routing table looks like this:
router#show ip route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0
S* 0.0.0.0/0 [5/0] via 10.0.0.1
4.0.0.0/32 is subnetted, 2 subnets
S 4.2.2.1 [1/0] via 10.0.0.1
S 4.2.2.2 [1/0] via 77.77.77.93
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet0/2
L 10.0.0.2/32 is directly connected, GigabitEthernet0/2
69.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 55.55.55.0/28 is directly connected, GigabitEthernet0/0
L 55.55.55.1/32 is directly connected, GigabitEthernet0/0
The routing table changes all by itself. Pretty cool. Now, there is the issue of the whole "private IP range on a public network thing" that we need to address. There is no NAT'ing on the MetroE side. Its already NAT'ed from the Pix thats behind the router (to the customer internal network). However, there are two other scenarios that play out. Number 1: What happens to the traffic going across the private network if the MetroE goes down? and Number 2: What happens to the traffic thats connected directly to the DSL modem or wireless DSL traffic?
Number1: If the MetroE goes down, then traffic is routed out the DSL link. But, you say, the 55.55.55 network cant go out the DSL link, because the traffic would just go out the DSL and come back to the MetroE side (which is down) because the MetroE ISP has that 55.55.55 range. Well, ok. Lets NAT it (do a double NAT). So if you look at this statement below, it says to NAT the traffic that matches the route-map and its applied to Gig0/2. Use Gig0/2's PRIVATE IP address. Wow, on the public network? Yep. But remember, at this point, you are on the PRIVATE DSL internal side of the DSL network. The packet just got NAT'ed from a 55.55.55 public IP to a 10.0.0 private IP. So when the packet gets to the DSL modem (which has the public IP address on its external interface), then it NATs the packet a third time (TRIPLE NAT!?!?!? --> Yep!).
So, lets look:
ip nat inside source route-map dialer interface GigabitEthernet0/2 overload
(this first "deny" says DONT NAT this criteria)
access-list 101 deny ip host 55.55.55.1 host 4.2.2.1
(these below say to NAT this criteria)
access-list 101 permit ip host 55.55.55.1 any
access-list 101 permit ip host 55.55.55.2 any
access-list 101 permit ip host 55.55.55.3 any
access-list 101 permit ip host 55.55.55.4 any
access-list 101 permit ip host 55.55.55.5 any
access-list 101 permit ip host 55.55.55.6 any
access-list 101 permit ip host 55.55.55.7 any
access-list 101 permit ip host 55.55.55.8 any
access-list 101 permit ip host 55.55.55.9 any
access-list 101 permit ip host 55.55.55.10 any
access-list 101 permit ip host 55.55.55.11 any
access-list 101 permit ip host 55.55.55.12 any
access-list 101 permit ip host 55.55.55.13 any
!
(The route-map says if you match ACL 101 AND go out Gig0/2, then apply to the "ip nat" statement above (its a match)):
route-map dialer permit 10
match ip address 101
match interface GigabitEthernet0/2
Number 2: If you are connected directly to the DSL modem, then it just NATs at the DSL modem. It never hits this router anyway. So, no worries there.
Here is what the config looks like. Ive taken out anything that doesn't really apply.
track 10 ip sla 1 reachability
delay down 2 up 2
!
track 20 ip sla 2 reachability
delay down 2 up 2
!
interface GigabitEthernet0/0
description PORT TO CUSTOMER PIX
ip address 55.55.55.1 255.255.255.240
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface GigabitEthernet0/1
description Metro-E ISP
ip address 77.77.77.94 255.255.255.252
duplex auto
speed auto
no cdp enable
no mop enabled
!
interface GigabitEthernet0/2
description TO DSL MODEM
ip address 10.0.0.2 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
no mop enabled
!
interface Dialer0
no ip address
ip flow ingress
ip nat outside
ip virtual-reassembly
encapsulation ppp
shutdown
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname xxxxxxxx
ppp chap password 0 xxxxxxxxx
ppp pap sent-username xxxxxxxx password 0 xxxxxxxxx
!
ip forward-protocol nd
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip nat inside source route-map dialer interface GigabitEthernet0/2 overload
ip route 0.0.0.0 0.0.0.0 77.77.77.93 track 10
ip route 0.0.0.0 0.0.0.0 10.0.0.1 5 track 20
ip route 4.2.2.1 255.255.255.255 10.0.0.1 permanent
ip route 4.2.2.2 255.255.255.255 77.77.77.93 permanent
!
ip sla 1
icmp-echo 4.2.2.2 source-ip 77.77.77.94
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.1 source-interface GigabitEthernet0/2
frequency 5
ip sla schedule 2 life forever start-time now
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 101 deny ip host 55.55.55.1 host 4.2.2.1
access-list 101 permit ip host 55.55.55.1 any
access-list 101 permit ip host 55.55.55.2 any
access-list 101 permit ip host 55.55.55.3 any
access-list 101 permit ip host 55.55.55.4 any
access-list 101 permit ip host 55.55.55.5 any
access-list 101 permit ip host 55.55.55.6 any
access-list 101 permit ip host 55.55.55.7 any
access-list 101 permit ip host 55.55.55.8 any
access-list 101 permit ip host 55.55.55.9 any
access-list 101 permit ip host 55.55.55.10 any
access-list 101 permit ip host 55.55.55.11 any
access-list 101 permit ip host 55.55.55.12 any
access-list 101 permit ip host 55.55.55.13 any
!
route-map dialer permit 10
match ip address 101
match interface GigabitEthernet0/2
!
This is the retired Shane Killen personal blog, an IT technical blog about configs and topics related to the Network and Security Engineer working with Cisco, Brocade, Check Point, and Palo Alto and Sonicwall. I hope this blog serves you well. -- May The Lord bless you and keep you. May He shine His face upon you, and bring you peace.
Tuesday, June 28, 2011
Saturday, June 25, 2011
Blocking all web browsing, except certain websites on the Cisco ASA
On June 16th, I wrote a post about blocking certain websites with your ASA for companies that want to allow web traffic, but block websites like facebook or youtube. Well, now, I have come across a request to block all HTTP and HTTPS traffic, with exception to a couple of websites that are related to the company, but do not reside on their own web server internally. So, with that said, lets look at how to do that. Im going to use facebook and youtube again in my example here. So, lets get started.
Define your regular expression. Name the websites you want to allow (facebook and youtube here):
regex allowex1 "facebook\.com"
regex allowex2 "youtube\.com"
Here, you want to define an access-list that specifies what traffic you want to fall under this inspection. In this case, it will be everyone in the company. However, you can define only certain hosts if you want. If you want to exclude any host from this, you will do this with a deny statement. Keep in mind the order of your ACL.
access-list user-acl permit tcp any any eq www
access-list user-acl permit tcp any any eq https
Create your class-map for inspection:
class-map type inspect http match-all allow-url-class
match not request header host regex allowex1
match not request header host regex allowex2
Create your second class-map and include what you just created above:
class-map allow-user-class
match access-list user-acl
Policy-map creation with what to do with the traffic:
policy-map type inspect http allow-url-policy
parameters
class allow-url-class
drop-connection
Policy-map with inspection:
policy-map allow-user-url-policy
class allow-user-class
inspect http allow-url-policy
Apply the policy-map to an interface (inside in this case):
service-policy allow-user-url-policy interface inside
Thats all you have to do. You should now be able to only browse facebook and youtube, and all other HTTP and HTTPS traffic will be denied.
Define your regular expression. Name the websites you want to allow (facebook and youtube here):
regex allowex1 "facebook\.com"
regex allowex2 "youtube\.com"
Here, you want to define an access-list that specifies what traffic you want to fall under this inspection. In this case, it will be everyone in the company. However, you can define only certain hosts if you want. If you want to exclude any host from this, you will do this with a deny statement. Keep in mind the order of your ACL.
access-list user-acl permit tcp any any eq www
access-list user-acl permit tcp any any eq https
Create your class-map for inspection:
class-map type inspect http match-all allow-url-class
match not request header host regex allowex1
match not request header host regex allowex2
Create your second class-map and include what you just created above:
class-map allow-user-class
match access-list user-acl
Policy-map creation with what to do with the traffic:
policy-map type inspect http allow-url-policy
parameters
class allow-url-class
drop-connection
Policy-map with inspection:
policy-map allow-user-url-policy
class allow-user-class
inspect http allow-url-policy
Apply the policy-map to an interface (inside in this case):
service-policy allow-user-url-policy interface inside
Thats all you have to do. You should now be able to only browse facebook and youtube, and all other HTTP and HTTPS traffic will be denied.
Thursday, June 23, 2011
How To SSH From A Cisco Router/Switch to Another Cisco Router/Switch
I occasionally run into situations where I need to SSH into an ASA (or
sometimes a router) and I cant get to them from the remote site Im
sitting at at that moment. So, how do I normally go about doing that if
I cant get to a server with putty? Ill SSH (or telnet) to a Cisco
router that I CAN get to. Then, because I cant use putty or anything
else to get to my ASA (which only allows SSH access), I simply do the
following: "ssh -l skillen 192.168.1.1". So, use the SSH command, -l
means "username", which is "skillen" for me, and then the target address
you are trying to reach (192.168.1.1). I have found this to be helpful
to me in several situations where Im trying to reach something, but
cant, and I only have access to another router (that might have access
to what I really want to). Interesting stuff.
sometimes a router) and I cant get to them from the remote site Im
sitting at at that moment. So, how do I normally go about doing that if
I cant get to a server with putty? Ill SSH (or telnet) to a Cisco
router that I CAN get to. Then, because I cant use putty or anything
else to get to my ASA (which only allows SSH access), I simply do the
following: "ssh -l skillen 192.168.1.1". So, use the SSH command, -l
means "username", which is "skillen" for me, and then the target address
you are trying to reach (192.168.1.1). I have found this to be helpful
to me in several situations where Im trying to reach something, but
cant, and I only have access to another router (that might have access
to what I really want to). Interesting stuff.
How To Replace A Cisco UC500 With Different UC500 Hardware
First, I TFTP'ed the startup-config to the replacement unit. Natrually, because of the differences in licenses and hardware, it didnt like my config from the original unit. Although it did take alot of what was in there. Here is what I ran into.
Because of the config, specifically the 'telephony-service' config, I needed to keep the same flash I had in the original UC520. Why? Because the phone loads that were in the config were on that flash. Not to mention the IOS for specific features that may have been needed. So, with that said, the first thing I had to do was to get that original flash out and put it in the replacement UC500. No big deal, you just have to think about it.
The second thing I had to do was to take out the PVDM2-64 that was in the original and put it in the replacement UC500 (which had a PVDM2-8). Now, for this reason, because I had a partial PRI coming in, I didnt have enough resources to get the PRI up with the replacement PVDM. So, with that said, I had to change it out. No big deal, just had to think of it. To the left is a picture of what a PVDM looks like.
NOTE: When taking the screws out to get into the inside of the unit, there is one embedded screw behind the faceplate that will drive you nuts. You cant see it until you get the faceplate off. See here to the left.
The third thing I had to do was to change some of the config in the ephone-DNs and ephones. Why? Again, the user licenses for ephones and ephone-DNs. I was only allowed up to 56 ephone-DNs with the replacement, and only 14 phones total (even though it was an 8 user license) with the replacement unit. So, ephone-DN and ephone numbers had to be changed (i.e. 'ephone-dn 65 dual line' had to become less than 56 / 'ephone 28' had to become 'ephone 5'). I had to get the customer to select what phones they wanted to keep and what phones they wanted to do without (again, because of user licenses) and number them appropriately (according to what the replacement would allow). No big deal, just had to work though that. This took some time though. I also had to sacrifice some phones due to ATAs that were needed for credit card machines, faxes, and security alarms. No big deal, but still had to account the ATA count in the ephone number allowed.
Physically replacing the unit was not a big deal (although I was reaching above my head while standing on a rolling chair - NOT fun). I just labeled the wiring and where it went and matched it up with the replacement. That saved time since I didn't have to remember anything. I just looked at the cable.
One thing I forgot to mention was that I had to take out the T1 module out of the unit that went bad and put it in the replacement unit. I didnt have one, so I had to use that module.
Anyway, just some thoughts on my experience on changing out one UC for another with different licenses and hardware.
Tuesday, June 21, 2011
Policy Based Routing: How To Configure A Route-Map On A Cisco 2800 Router To Make Traffic Go In Two Different Directions
Well, I'm excited tonight to post this posting. Ive been doing ASA postings so far, but tonight I'd like to do a router post. I have this customer that came to me and told me that they had this Nortel Contivity firewall, and that they felt it was overloaded and causing major performance issues for Internet traffic. They initially wanted to just buy an ASA and let that be that. However, upper management DIDN'T want them to do that, because they had a second Nortel Contivity sitting around, being of no use at all. Their question: "How can we use that"? Well, because they initially wanted me to put a Cisco 2800 in place of the firewall, I told them I could use that router to route some traffic to the current firewall, and the other traffic to the other firewall. The topology would look like this:
So, with this topology above, I took the Cisco router and decided to route half of their traffic to the original Contivity firewall, and the rest of the traffic to the new (the used one sitting on the shelf) Contivity firewall. Again, because of performance issues on the original Contivity. How would I do this? Route-Maps! I remember on of my past bosses telling me that "thems the big boys". I didn't understand what he meant then, but I do nowadays. You can manipulate traffic almost anyway you want with these "big boys". I've come to really like these route-maps a lot, so lets dive into what I did today for this customer. Ive cut this down quite a bit just for this example.
First, I need to determine what traffic needs to go where. I have two firewalls here, in parallel with each other. So, what traffic do I want to go to the first firewall, and what do I want to go to the second firewall? Well, lets define out traffic:
Access-list 170 is going to say this: Any traffic from sourced from 192.168.41.0 and 192.168.137.0 and destined to any network is our target networks. Also, I DON'T want any traffic sourced from 10.0.0.0 networks and destined for 192.168.2.0 networks to be a part of this, or any other traffic (specified by the deny ip any any).
access-list 170 deny ip 10.0.0.0 0.255.255.255 192.168.2.0 0.0.0.255
access-list 170 permit ip 192.168.41.0 0.0.0.255 any
access-list 170 permit ip 192.168.137.0 0.0.0.255 any
access-list 170 deny ip any any
My second access-list 171. Similar to above, but different networks.
access-list 171 deny ip 10.0.0.0 0.255.255.255 192.168.2.0 0.0.0.255
access-list 171 permit ip 192.168.129.0 0.0.0.255 any
access-list 171 permit ip 192.168.130.0 0.0.0.255 any
access-list 171 deny ip any any
Now, the route-map. The first three lines of the route-map LoadBal refer to access-list 170. Anything that matches ACL 170 (the permits), the traffic is to be sent to the next-hop of 192.168.190.254. In the second set of three, anything that matches ACL 171 will be sent to 192.168.190.253 (again, the permits only).
route-map LoadBal permit 10
match ip address 170
set ip next-hop 192.168.190.254
route-map LoadBal permit 20
match ip address 171
set ip next-hop 192.168.190.253
Now, we have to apply this route-map to an interface. Really easy to do. Just reference the route-map name, which you gave in the first line and fourth line above.
interface fa0/0
ip policy route-map LoadBal
That's it. Can you image how complex you can get with this? Literally, your imagination is the limit.
So, with this topology above, I took the Cisco router and decided to route half of their traffic to the original Contivity firewall, and the rest of the traffic to the new (the used one sitting on the shelf) Contivity firewall. Again, because of performance issues on the original Contivity. How would I do this? Route-Maps! I remember on of my past bosses telling me that "thems the big boys". I didn't understand what he meant then, but I do nowadays. You can manipulate traffic almost anyway you want with these "big boys". I've come to really like these route-maps a lot, so lets dive into what I did today for this customer. Ive cut this down quite a bit just for this example.
First, I need to determine what traffic needs to go where. I have two firewalls here, in parallel with each other. So, what traffic do I want to go to the first firewall, and what do I want to go to the second firewall? Well, lets define out traffic:
Access-list 170 is going to say this: Any traffic from sourced from 192.168.41.0 and 192.168.137.0 and destined to any network is our target networks. Also, I DON'T want any traffic sourced from 10.0.0.0 networks and destined for 192.168.2.0 networks to be a part of this, or any other traffic (specified by the deny ip any any).
access-list 170 deny ip 10.0.0.0 0.255.255.255 192.168.2.0 0.0.0.255
access-list 170 permit ip 192.168.41.0 0.0.0.255 any
access-list 170 permit ip 192.168.137.0 0.0.0.255 any
access-list 170 deny ip any any
My second access-list 171. Similar to above, but different networks.
access-list 171 deny ip 10.0.0.0 0.255.255.255 192.168.2.0 0.0.0.255
access-list 171 permit ip 192.168.129.0 0.0.0.255 any
access-list 171 permit ip 192.168.130.0 0.0.0.255 any
access-list 171 deny ip any any
Now, the route-map. The first three lines of the route-map LoadBal refer to access-list 170. Anything that matches ACL 170 (the permits), the traffic is to be sent to the next-hop of 192.168.190.254. In the second set of three, anything that matches ACL 171 will be sent to 192.168.190.253 (again, the permits only).
route-map LoadBal permit 10
match ip address 170
set ip next-hop 192.168.190.254
route-map LoadBal permit 20
match ip address 171
set ip next-hop 192.168.190.253
Now, we have to apply this route-map to an interface. Really easy to do. Just reference the route-map name, which you gave in the first line and fourth line above.
interface fa0/0
ip policy route-map LoadBal
That's it. Can you image how complex you can get with this? Literally, your imagination is the limit.
Thursday, June 16, 2011
Cisco ASA 8.3: How To Configure "No NAT'ing" For Remote-Access Clients
Ok, this is a real pain. The new 8.3 code on the ASA has changed, as
Ive indicated in previous postings on this site. One of the things Ive
forgotten about is the remote-access users. I actually had a customer
of mine tell me that they could VPN in, but that they could no longer
RDP to anything anymore. So, guess what? There is not more nonat
statement:
Pre-8.3 code:
nat (inside) 0 access-list nonat
Well now, its going to look somewhat different. And to me, its
absolutely almost crazy thinking. However, since they didnt ask me,
here is what I had to do:
8.3 code:
object network LOCAL_LAN <------ Inside Network
subnet 192.168.10.0 255.255.255.0 <------ Inside Network IP Range
object network REMOTE_LAN
subnet 192.168.150.0 255.255.255.0 <------ VPN Pool IP Range
nat (inside,outside) source static LOCAL_LAN LOCAL_LAN destination
static REMOTE_LAN REMOTE_LAN
Now here is an explanation of the NAT syntax, because if you are like
me, the NAT statement makes no sense:
nat (real interface,mapped interface) source static [real_object]
[mapped_object] destination static [real_object] [mapped_object]
So, when I put this in on my customer, I could then get to what I needed
to again. All is good.
Ive indicated in previous postings on this site. One of the things Ive
forgotten about is the remote-access users. I actually had a customer
of mine tell me that they could VPN in, but that they could no longer
RDP to anything anymore. So, guess what? There is not more nonat
statement:
Pre-8.3 code:
nat (inside) 0 access-list nonat
Well now, its going to look somewhat different. And to me, its
absolutely almost crazy thinking. However, since they didnt ask me,
here is what I had to do:
8.3 code:
object network LOCAL_LAN <------ Inside Network
subnet 192.168.10.0 255.255.255.0 <------ Inside Network IP Range
object network REMOTE_LAN
subnet 192.168.150.0 255.255.255.0 <------ VPN Pool IP Range
nat (inside,outside) source static LOCAL_LAN LOCAL_LAN destination
static REMOTE_LAN REMOTE_LAN
Now here is an explanation of the NAT syntax, because if you are like
me, the NAT statement makes no sense:
nat (real interface,mapped interface) source static [real_object]
[mapped_object] destination static [real_object] [mapped_object]
So, when I put this in on my customer, I could then get to what I needed
to again. All is good.
How To Block Websites With Your Cisco ASA
MPF provides a consistent and flexible way to configure security appliance features. For example, you can use MPF to create a timeout configuration that is specific to a particular TCP application, as opposed to one that applies to all TCP applications.
MPF supports these features:
TCP normalization, TCP and UDP connection limits and timeouts, and TCP sequence number randomization
CSC
Application inspection
IPS
QoS input policing
QoS output policing
QoS priority queue
The configuration of the MPF consists of four tasks:
Identify the Layer 3 and 4 traffic to which you want to apply actions.
(Application inspection only) Define special actions for application inspection traffic.
Apply actions to the Layer 3 and 4 traffic.
Activate the actions on an interface.
Remember, we just want to block facebook and youtube. You can get very granular in what you want to block, but for this example, we will just do the two websites. Topology will look like this:
Here is how we configure:
Define the Regex for the domain you wish to block:
regex blockex1 "facebook\.com"
regex blockex2 "youtube\.com"
Create a class map statement that matches your regex
class-map type inspect http match-any block-url-class
match request header host regex blockex1
match request header host regex blockex2
Create a broader policy map to include HTTP traffic and specify the previous class map
policy-map type inspect http block-url-policy
parameters
class block-url-class
drop-connection log
Apply inspect to your default policy:
policy-map global_policy
class inspection_default
inspect http block-url-policy
Apply your policy:
service-policy global_policy global
Now, if you go to facebook.com or youtube.com, you will not get anything in the browser. It basically just looks like nothing ever resolved in DNS. However, one little odd thing does happen that Ive noticed. If the user has the website up in their browser, and then you apply this config, they will still be able to get to it until they close their browser out. Im not sure why at the moment why that happens, but I do know for sure if they close the browser out and reopen, then they wont be able to get to the websites you listed. Very strange behavior, but something you can easily overcome with a reboot of all systems if needed.
Thursday, June 9, 2011
Cisco ASA Hairpinning: How To Configure Remote Site Source Traffic To Second Remote Site Destination Across Site To Site VPNs
Well, tonight I had an issue where I needed to make a voip softphone work on a laptop via VPN. No worries. I configured a vpn remote-access client and all worked great for the softphone to work well. However, I did run into one issue. The softphone couldnt not reach the internal extensions of the office, which happened to be across a site-to-site VPN tied to the same Cisco ASA that I (the remote-access client) was VPN'ed into. Interesting. So, with successful site-to-site VPN and successful remote-access VPN configured, and appropriate changes to the site-to-site VPN (on both sides) to allow the new softphone traffic, I still couldnt get the softphone to reach the internal office phones across the site-to-site VPN. Well, there is such a thing in Cisco called "hairpinning". Hairpinning is where you come in one VPN tunnel and try to go out a different VPN tunnel. Below is what Hairpinning looks like, from one laptop to another:

Now, to resolve this, it only took one command on the ASA:
same-security-traffic permit intra-traffic
Without this command, it wouldnt work. But, when I put this in, I got good results and Im very happy.

Now, to resolve this, it only took one command on the ASA:
same-security-traffic permit intra-traffic
Without this command, it wouldnt work. But, when I put this in, I got good results and Im very happy.
Tuesday, June 7, 2011
How To Configure A Cisco ASA To Authenticate Remote-Access Users With Microsoft LDAP/Active Directory
Today I had the opportunity to configure an ASA to be integrated with
Active Directory. My customer only wanted (at this point) to have vpn
remote-access users authenticate through AD. So, being a little "not"
well versed in AD stuff, I had to employ the help of my customer. I
showed him an example of what I needed (shown below in #1) and he filled
in the blanks (#2).
#1, from a document I found:
ciscoasa#configure terminal
!−−− Configure the AAA Server group.
ciscoasa(config)#aaa−server LDAP_SRV_GRP protocol ldap
!−−− Configure the AAA Server.
ciscoasa(config−aaa−server−group)#aaa−server LDAP_SRV_GRP (inside) host
192.168.1.2
ciscoasa(config−aaa−server−host)#ldap−base−dn dc=ftwsecurity, dc=cisco,
dc=com
ciscoasa(config−aaa−server−host)#ldap−login−dn cn=admin, cn=users,
dc=ftwsecurity, dc=cisco, dc=com
ciscoasa(config−aaa−server−host)#ldap−login−password **********
ciscoasa(config−aaa−server−host)#ldap−naming−attribute sAMAccountName
ciscoasa(config−aaa−server−host)#ldap−scope subtree
ciscoasa(config−aaa−server−host)#server−type microsoft
ciscoasa(config−aaa−server−host)#exit
#2, Here below is what I got from the Microsoft guy at my customer (a
little changed to protect the company):
aaa-server LDAP_SRV_GRP protocol ldap
aaa-server LDAP_SRV_GRP (inside) host 192.168.1.10
ldap-base-dn dc=ad, dc=company, dc=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password testpassword
ldap-login-dn cn=SVC_LDAPQUERY, ou=ServiceAccounts,
ou=SpecialPurposeUsers, ou=AdministrativeSpecial-GroupsAndUsers, dc=ad,
dc=company, dc=com
server-type microsoft
I then applied this for my remote-access users so that they would use AD
to authenticate with:
tunnel-group testtunnelgroup general-attributes
authentication-server-group LDAP_SRV_GRP
By the way, one note that I noticed that is different than using RADIUS.
On the user properties, I did NOT have to select "allow" on the dial-in
tab. A big time saver if you have a lot of users. NOR did I have to
create a group, like I normally would with RADIUS. However, if I wanted
to allow certain users and deny others, that might be research into
another posting. Hmmm.
Anyway, to test from the ASA to see if authentication is working, I used
the following command:
ASA# test aaa-server authentication LDAP_SRV_GRP host 192.168.1.10
username testuser password pass*
INFO: Attempting Authentication test to IP address <192.168.1.10>
(timeout: 12 seconds)
INFO: Authentication Successful
Really, its a lot less work than setting up RADIUS. However, again,
there may be situations that you may prefer RADIUS over LDAP for AD
integration.
Active Directory. My customer only wanted (at this point) to have vpn
remote-access users authenticate through AD. So, being a little "not"
well versed in AD stuff, I had to employ the help of my customer. I
showed him an example of what I needed (shown below in #1) and he filled
in the blanks (#2).
#1, from a document I found:
ciscoasa#configure terminal
!−−− Configure the AAA Server group.
ciscoasa(config)#aaa−server LDAP_SRV_GRP protocol ldap
!−−− Configure the AAA Server.
ciscoasa(config−aaa−server−group)#aaa−server LDAP_SRV_GRP (inside) host
192.168.1.2
ciscoasa(config−aaa−server−host)#ldap−base−dn dc=ftwsecurity, dc=cisco,
dc=com
ciscoasa(config−aaa−server−host)#ldap−login−dn cn=admin, cn=users,
dc=ftwsecurity, dc=cisco, dc=com
ciscoasa(config−aaa−server−host)#ldap−login−password **********
ciscoasa(config−aaa−server−host)#ldap−naming−attribute sAMAccountName
ciscoasa(config−aaa−server−host)#ldap−scope subtree
ciscoasa(config−aaa−server−host)#server−type microsoft
ciscoasa(config−aaa−server−host)#exit
#2, Here below is what I got from the Microsoft guy at my customer (a
little changed to protect the company):
aaa-server LDAP_SRV_GRP protocol ldap
aaa-server LDAP_SRV_GRP (inside) host 192.168.1.10
ldap-base-dn dc=ad, dc=company, dc=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password testpassword
ldap-login-dn cn=SVC_LDAPQUERY, ou=ServiceAccounts,
ou=SpecialPurposeUsers, ou=AdministrativeSpecial-GroupsAndUsers, dc=ad,
dc=company, dc=com
server-type microsoft
I then applied this for my remote-access users so that they would use AD
to authenticate with:
tunnel-group testtunnelgroup general-attributes
authentication-server-group LDAP_SRV_GRP
By the way, one note that I noticed that is different than using RADIUS.
On the user properties, I did NOT have to select "allow" on the dial-in
tab. A big time saver if you have a lot of users. NOR did I have to
create a group, like I normally would with RADIUS. However, if I wanted
to allow certain users and deny others, that might be research into
another posting. Hmmm.
Anyway, to test from the ASA to see if authentication is working, I used
the following command:
ASA# test aaa-server authentication LDAP_SRV_GRP host 192.168.1.10
username testuser password pass*
INFO: Attempting Authentication test to IP address <192.168.1.10>
(timeout: 12 seconds)
INFO: Authentication Successful
Really, its a lot less work than setting up RADIUS. However, again,
there may be situations that you may prefer RADIUS over LDAP for AD
integration.
Monday, June 6, 2011
Cisco ASA: How To Translate Multiple Global IP Addresses NAT'ed To A Single Local IP Address
Hello all. Today I wanted to talk about a need that occasionally will arise in the networking world. I have been asked to have two public IP addresses mapped to one private IP address. Why would I want to do this? Well, I have had a few customers with several different needs for this sort of thing. One in particular has been that the customer had two external DNS entries pointing to two different mail servers for two different companies. Well, what happens if they decide to implement a single spam filter for both mail servers? You get two public IPs pointing to one private address (if your spam filter in internal to the network). Now, I looked into this and I was told by Cisco TAC that you could not do this (effectively) with the PRE-8.3 ASA code. I was told (by Cisco TAC) that I would need to upgrade to at least the 8.3 or greater code to be able to accomplish this. So, with each case as the need has arose, Ive done the upgrade.
Ok, so with the PRE-8.3 code, here is what the static NAT looks like:
static (inside,outside) tcp 64.130.108.42 smtp 192.168.1.11 smtp
Now, if you try to accomplish what we have talked about so far with the PRE-8.3 code, you are going to get the ASA complaining to you:
PRE-8.3 code would look like this:
static (inside,outside) tcp 1.1.1.42 smtp 192.168.1.10 smtp
static (inside,outside) tcp 1.1.1.41 smtp 192.168.1.10 smtp
Now, when you press "ENTER" after the second line, the ASA is going to say:
"ERROR: duplicate of existing static
inside:192.168.1.10 to outside:1.1.1.42 netmask 255.255.255.255"
Obviously, this is not cool if you are trying to solve this problem.
So, here is how we solve the problem. We do the 8.3 upgrade, then we do the below commands:
8.3 code looks like this:
object network obj-192.168.1.10-01
host 192.168.1.10
nat (inside,outside) static 1.1.1.42 service tcp smtp smtp
object network obj-192.168.1.10-02
host 192.168.1.10
nat (inside,outside) static 1.1.1.41 service tcp smtp smtp
Easy as that. Now, if I telnet to these two public IPs from the outside (to port 25), I get Exchange server messages.
Ok, so with the PRE-8.3 code, here is what the static NAT looks like:
static (inside,outside) tcp 64.130.108.42 smtp 192.168.1.11 smtp
Now, if you try to accomplish what we have talked about so far with the PRE-8.3 code, you are going to get the ASA complaining to you:
PRE-8.3 code would look like this:
static (inside,outside) tcp 1.1.1.42 smtp 192.168.1.10 smtp
static (inside,outside) tcp 1.1.1.41 smtp 192.168.1.10 smtp
Now, when you press "ENTER" after the second line, the ASA is going to say:
"ERROR: duplicate of existing static
inside:192.168.1.10 to outside:1.1.1.42 netmask 255.255.255.255"
Obviously, this is not cool if you are trying to solve this problem.
So, here is how we solve the problem. We do the 8.3 upgrade, then we do the below commands:
8.3 code looks like this:
object network obj-192.168.1.10-01
host 192.168.1.10
nat (inside,outside) static 1.1.1.42 service tcp smtp smtp
object network obj-192.168.1.10-02
host 192.168.1.10
nat (inside,outside) static 1.1.1.41 service tcp smtp smtp
Easy as that. Now, if I telnet to these two public IPs from the outside (to port 25), I get Exchange server messages.
Subscribe to:
Posts (Atom)