Connect IPS ASA5510 to CSC ASA5510

Answered Question
Aug 18th, 2010

Hello all,


I’m trying to figure out the best way to connect two ASA 5510’s together and have run into a bit of a snag.  I have two ASA 5510's, one has a CSC-SSM and will act as a Firewall, Antivirus and VPN (I'll call it the CSCASA) and the other has an AIP-SSM and will be solely used for IPS (I'll call it the IPSASA).


I had the CSCASA setup and working fine using PAT and tcp bypass (so I can get to my networks behind the MPLS) but now I want to put the IPSASA between my LAN and the CSCASA.  I know that I will have to move the tcp bypass settings and static routes over to the IPSASA.


The CSCASA Ethernet 0/0 will connect to my ISP, Ethernet 0/1 will connect to Ethernet 0/0 on the IPSASA.  Ethernet 0/1 on the IPSASA will connect to my LAN switch.  I would like to have all inbound traffic flowing through the IPSASA scanned by the IPS and outbound traffic not scanned.


We are using several different networks (all 192.168.xxx.0).  Some of these networks are remote offices that connect to our corporate network (192.168.120.0) through an MPLS network.  All Internet traffic will go through the 192.168.120.0 network and out the IPSASA and CSCASA.  I thought I would be able to assign CSCASA Ethernet 0/1 a 192.168.120.x address and IPSASA Ethernet 0/0 a 192.168.120.x address but I was not able to do this.  Cisco recommended I use a different address to connect these two interfaces so I am using 192.168.230.1 and 192.168.230.2 for the respective interfaces.


What is the proper way to handle NAT in a situation like this with two ASA's?  I can't see the point in having two devices performing NAT on traffic.  I tried using "nat (inside) 0 192.168.0.0 255.255.0.0 0 0" on the IPSASA but it doesn't seem to work.


Please let me know if I am way off base here.  Thanks for your help.

Correct Answer by praprama about 6 years 5 months ago

Hi Neil,


I see where the problem lies. Dont know how i missed it all this while. Anyway, add the below commands and see if it fixes the issue:


static (LAN,FW) 192.168.100.8 192.168.100.8

static (LAN,FW) 192.168.100.10 192.168.100.10

static (LAN,FW) 192.168.100.38 192.168.100.38

static (LAN,FW) 192.168.100.112 192.168.100.112


I am assuming these are the only 4 servers. If there are more, you will need to add the same commands for them as well. Also, in future, as you add newer servers, you will need to add the same command for them as well.


You can avoid this by just simply removing the command "nat-control" and hence you can remove the command "nat (LAN) 0 192.168.0.0 255.255.0.0" as well.


You can try out either of the above options. Let me know how it goes!!


Regards,

Prapanch

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
praprama Wed, 08/18/2010 - 09:34

Hi,


Here is my understanding of your topology:



192.168.0.0/16------------IPSASA(E0/0)--------------------------------(E0/1)CSCASA(E0/0)-----ISP

                                              192.168.230.1          192.168.230.2



By using the command nat (inside) 0 192.160.0.0 255.255.0.0, you are creating identity NAT on the IPS ASA.That means, each host will be translated to itself.


> I tried using "nat (inside) 0 192.168.0.0 255.255.0.0 0 0" on the  IPSASA but it doesn't seem to work.


What is not working? Do you mean internet access is not working for the entire 192.168.0.0/16 network? If so, what NAT config do you have on the CSCASA?


Regards,

Prapanch

hnbbank01 Thu, 08/19/2010 - 11:51

Prapanch,


You are correct with regards to the topology and yes I am unable to get to the internet.


Here's the NAT settings on the CSCASA which were working prior to me installing the IPSASA.

nat-control
global (WAN) 101 interface
nat (LAN) 101 0.0.0.0 0.0.0.0


Thanks.

Neil

praprama Thu, 08/19/2010 - 19:24

Hi,


That seems alright.Can you please run packet-tracers and enable logs and see what you get there?


Also, instead of have an identity NAT on the IPSASA, can you have a similar dynamic NAT on that as well and see if it makes any difference?


Regards,

Prapanch

hnbbank01 Thu, 09/02/2010 - 07:57

Prapanch,


Sorry for the delay, I had an ASAP project pop up and then got hit with Active Directory problems.


I managed to get the two IPS's working and I now have internet access and access to my remote offices.  Turns out, I had a couple of routes that were not correct.  I had the routes pointing to the local interface instead of the next ASA interface.


My problem now is that I am getting "No translation group found" errors in the IPSASA log.

3 Aug 30 2010 10:13:12 305005 192.168.100.112 514   No translation group found for udp src FW:192.168.251.2/514 dst LAN:192.168.100.112/514
3 Aug 30 2010 10:12:50 305005 192.168.100.10 123   No translation group found for udp src FW:192.168.251.2/65535 dst LAN:192.168.100.10/123
3 Aug 30 2010 10:18:42  305005 192.168.100.8 53 No translation group found for udp src FW:192.168.251.2/13602 dst LAN:192.168.100.8/53

192.168.100.8, 192.168.100.10 and 192.168.100.112 are my internal DNS/NTP and syslog servers.

On the CSCASA, I have these errors in the log.
2 Aug 30 2010 10:07:44  113022 AAA Marking LDAP server "server name" in aaa-server group LDAP_SRV_GROUP as FAILED
2 Aug 30 2010 10:08:32  106016 Deny IP spoof from (192.168.251.2) to 192.168.100.10 on interface LAN


I figured it was a NAT issue but nothing I've tried has worked.  Any ideas?


FYI, I had to tweak my IP addresses.  192.168.230.1 and 192.168.230.2 have been changed to 192.168.250.1 and 192.168.250.2.
192.168.0.0/16------------IPSASA(E0/0)--------------------------------(E0/1)CSCASA(E0/0)-----ISP
                                      192.168.250.1          192.168.250.2

Thanks.


Neil

praprama Thu, 09/02/2010 - 08:08

Hi,


The logs on the IPSASA are certainly to do with NAT and the reson for the IP Spoof message on the CSCASA could also be the same. Can you attach the current configs on the IPSASA and CSCASA (with public IP addresses modified if needed)?


The explanation for the first message releatd to LDAP on the CSCASA can be found below:


http://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi?caller=pluginredirector&action=search&locale=en&index=all&counter=0&paging=5&sa=Submit&query=%25ASA-2-113022


Regards,

Prapanch

praprama Thu, 09/02/2010 - 18:56

Hi,


1) 3 Aug 30 2010 10:13:12 305005 192.168.100.112 514   No translation group  found for udp src FW:192.168.251.2/514 dst LAN:192.168.100.112/514
3  Aug 30 2010 10:12:50 305005 192.168.100.10 123   No translation group  found for udp src FW:192.168.251.2/65535 dst LAN:192.168.100.10/123
3  Aug 30 2010 10:18:42  305005 192.168.100.8 53 No translation group  found for udp src FW:192.168.251.2/13602 dst LAN:192.168.100.8/53


All the above messages you are getting are from the CSCASA's inside IP address 192.168.251.2 to servers on the LAN side of the IPSASA. Now on the IPSASA's FW interface the ACL perimts all IP traffic so that is alright. the reason why we are getting these errors are because of the following on the IPSASA:


nat-control


This command says that for any traffic traversing the firewall, it has to match one NAT rule on it. Now when the CSCASA accesses say the DNS server 192.168.100.8, when this packets reaches the IPSASA, it can not find any NAT rule for the DNS server 192.168.100.8 and hence drops the packet.


Now there are a couple of ways that i think we can get this working on the IPSASA:


1) disable nat-control using "no nat-control".

2) Add a static transltion for exvery server as below:


static (LAN,FW) 192.168.10.8 192.168.100.8 and so on.


What this will do is translate all the servers to the same IP address on the FW interface of the IPSASA.


3) add a nat exemption rule for each of the servers the CSCASA needs to talk to as below:


access-list nat0 permit ip host 192.168.100.8 host 192.168.251.2


nat (LAN) 0 access-list nat0


This would basically disable NAT for traffic flowing between the CSCASA and all the servers you add on the above ACL.


2) 2 Aug 30 2010 10:08:32  106016 Deny IP spoof from (192.168.251.2) to  192.168.100.10 on interface LAN


This message that you are seeing on the CSCASA is weird. The CSCASA is getting a packet on the LAN interface with source ip as 192.168.251.2 (which is it's own IP address) destined for 192.168.100.10. this is why it's dropping it. I am not sure why such a packet is coming to the CSCASA. You might want to have a check on that by running captures on the CSCASA and the IPSASA.


Let me know if this helps!!


Thanks and Regards,

Prapanch

hnbbank01 Fri, 09/03/2010 - 13:07

Prapanch,


I used the access-list nat0 permit ip host 192.168.100.8 host 192.168.251.2 and nat (LAN) 0 access-list nat0 commands you suggested and they worked great.  No more translation group errors.  Thank you for figuring out that problem.


The problem with the Deny IP spoof on the CSCASA is another matter.  The CSCASA is not able to get to 192.168.100.10 for ping, DNS or LDAP queries.  I'll run some captures and see what I find.


Enjoy the weekend!


Neil

hnbbank01 Wed, 09/08/2010 - 13:08

I figured out the problem with the errors on the CSCASA and they tie in with the nat0 commands.  With the nat0 commands in place, 192.168.251.2 is not getting translated so when it hits my server (192.168.100.10), my server is sending the traffic to it's default gateway (which is a different router) and that router has no idea where 192.168.251.2 is.  If I put a static route on 192.168.100.10 that points traffic for 192.168.251.2 to 192.168.100.99 (IPSASA), everything works.


Is there a way to handle this using NAT to translate 192.168.251.2 to a 192.168.100.0 address that would solve this problem or do I have to add a static route to my other router?  I tried using dynamic NAT to translate 192.168.251.2 to the IPSASA LAN interface address (192.168.100.99 ) but that did not work.


Thanks again.

praprama Thu, 09/09/2010 - 06:58

Hi,


You can either use a static or a dynamic NAT. What kind of dynamic commands did you use on the IPSASA for NATting 192.168.251.2? Please paste the exact commands.


Regards,

Prapanch

hnbbank01 Thu, 09/09/2010 - 11:52

Hello,


I'm stumped.  Conceptually, I understand (at least I think I do) what needs to be done but applying it using the proper NAT commands is beyond me at this point.  This is what I think I need to get this to work: Traffic coming across the IPSASA FW interface with the address of 192.168.251.2 destined for 192.168.100.8, 192.168.100.10, etc. should get translated to the LAN interface address.


I've used various translations based on what I've read and I haven't gotten any of them to work.


This was my last attempt...

access-list CSC_to_Server extended permit ip host 192.168.251.2 host 192.168.100.8
access-list CSC_to_Server extended permit ip host 192.168.251.2 host 192.168.100.10
access-list CSC_to_Server extended permit ip host 192.168.251.2 host 192.168.100.38
access-list CSC_to_Server extended permit ip host 192.168.251.2 host 192.168.100.112

nat (FW) 25 access-list CSC_to_Server

global (LAN) 25 interface


Thanks.


Neil

praprama Thu, 09/09/2010 - 20:10

Everything is alright except we are missing one keyword in the nat command. try changing the nat command to look like below:


nat (FW) 25 access-list CSC_to_Server outside


The outside keyword is important when you want a dynamic NAT configured from a lower security level interface to higher security level interface.


Thanks and Regards,

Prapanch

hnbbank01 Fri, 09/10/2010 - 06:24

Prapanch,


I used nat (FW) 25 access-list CSC_to_Server outside as you suggested but I'm still getting "No translation group found" errors on the IPSASA.


3 Sep 10 2010 09:21:14 305005 192.168.100.112 514 No translation group found for udp src FW:192.168.251.2/514 dst LAN:192.168.100.112/514


Thanks.


Neil

praprama Fri, 09/10/2010 - 18:30

Hey Neil,


What happens when you use a "nat (FW) 25 192.168.251.2 255.255.255.255" instead?


Regards,

Prapanch

praprama Sat, 09/11/2010 - 05:47

Hey Neil,


Can you also attach the entire output of the below:


packet-tracer input FW udp 192.168.251.2 514 192.168.100.112 514 detail


Regards,

Prapanch

hnbbank01 Mon, 09/13/2010 - 05:55

Prapanch,


HNBASA55101# packet-tracer input FW udp 192.168.251.2 514 192.168.100.112 514


Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.100.0   255.255.255.0   LAN

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group FW_access_in in interface FW
access-list FW_access_in extended permit ip any any
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (FW) 25 access-list CSC_to_Server outside
nat-control
  match ip FW host 192.168.251.2 LAN host 192.168.100.112
    dynamic translation to pool 25 (192.168.100.99 [Interface PAT])
    translate_hits = 4724, untranslate_hits = 0
Additional Information:
Dynamic translate 192.168.251.2/514 to 192.168.100.99/939 using netmask 255.255.255.255

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (FW) 25 access-list CSC_to_Server outside
nat-control
  match ip FW host 192.168.251.2 FW host 192.168.100.8
    dynamic translation to pool 25 (No matching global)
    translate_hits = 0, untranslate_hits = 0
Additional Information:

Phase: 7
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (LAN) 0 192.168.0.0 255.255.0.0
nat-control
  match ip LAN 192.168.0.0 255.255.0.0 FW any
    identity NAT translation, pool 0
    translate_hits = 2541, untranslate_hits = 0
Additional Information:

Result:
input-interface: FW
input-status: up
input-line-status: up
output-interface: LAN
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Correct Answer
praprama Mon, 09/13/2010 - 06:13

Hi Neil,


I see where the problem lies. Dont know how i missed it all this while. Anyway, add the below commands and see if it fixes the issue:


static (LAN,FW) 192.168.100.8 192.168.100.8

static (LAN,FW) 192.168.100.10 192.168.100.10

static (LAN,FW) 192.168.100.38 192.168.100.38

static (LAN,FW) 192.168.100.112 192.168.100.112


I am assuming these are the only 4 servers. If there are more, you will need to add the same commands for them as well. Also, in future, as you add newer servers, you will need to add the same command for them as well.


You can avoid this by just simply removing the command "nat-control" and hence you can remove the command "nat (LAN) 0 192.168.0.0 255.255.0.0" as well.


You can try out either of the above options. Let me know how it goes!!


Regards,

Prapanch

hnbbank01 Wed, 09/15/2010 - 12:36

Prapanch,


That worked!  Thank you very much for solving that one.  It was driving me nuts.


My only problem now is configuring my IPSec VPN.  I had it setup so that it would give out a 192.168.100.0 address when logging on VPN users but with that address range, I'm getting translation errors.  I'm going to work on that and see if I can figure it out now that you gave me so much information on how this thing works.


Thanks again for all of your help.


Neil

praprama Wed, 09/15/2010 - 17:20

Hey Neil,


Glad that i could help. Please mark this post as Answered if all is resolved then.


Regards,

Prapanch

Actions

This Discussion