ASA 5505 Logging Issue - Warning: Configured logging host interface conflicts with route table entry

John Forester · ‎04-23-2013

I am getting this warning on my ASA 5505 when I try to set up logging from my off site FW to the central FW, which is a 5510. What I am trying to do is send the FW logs through the VPN Tunnel into the central 5510 to our logging server at 192.168.22.99, but allow all other traffic out the outside interface so customers can hit our web servers down there. Here is an example of my config with fake IP's. I get this error when trying to do "logging inside host 192.168.22.99". If I try to put in "logging Tunnel host 192.168.22.99" I get the "Warning:Security Level is 1" message

5505

ethe0/0

desc To LA ISP (217.34.122.1)

switchport access vlan2

ethe0/1

desc To Redwood City HQ via VPN Tunnel

switchport access vlan1

ethe0/2

desc To Internal Web Server

switchport access vlan3

VLAN1

desc Tunnel to HQ

ifinterface Tunnel

security level 1

217.34.122.3 255.255.255.248

VLAN3

desc Internal Web Server

ifinterface inside

security level 100

192.168.0.1 255.255.255.0

access-list LosAngeles extended permit ip 192.168.0.0 255.255.255.0 192.168.22.0 255.255.255.0

(No access-group is performed, as I match from the crypto map instead since I have multiple sites going out of HQ - see HQ configs)

route Tunnel 192.168.22.0 255.255.255.0 65.29.211.198

crypto map TO-HQ 10 match address LosAngeles

crypto map TO-HQ set peer ip 65.29.211.198

----------------------------------------------------------------------------------------------------------------------------------------------------------

5510 at HQ

access-list LA extended permit ip 192.168.22.0 255.255.255.0 192.168.0.0 255.255.255.0

(again no access-group, since I have a couple other off sites)

crypto map TO-LA 20 match address LA

crypto map TO-LA 20 set peer ip 217.34.122.3

Jouni Forss · ‎04-23-2013

Hi,

That warning message is something that always comes when you configure logging on a low security-level interface. It shouldnt stop the logging from working.

Though I would imagine that you have to configure the Branch Site public IP address into the Crypto Map ACL and then you could send the logs through the actual L2L VPN connection

For example

Branch ASA

access-list LosAngeles permit ip host 217.34.122.3 192.168.22.0 255.255.255.0

HQ ASA

access-list LA permit ip 192.168.22.0 255.255.255.0 host 217.34.122.3

This would allow the Branch ASA to send logs source from its "outside/Tunnel" IP address.

EDIT:

Actually the ACL could be cleaned to only include the Central Sites Syslog server IP

Branch ASA

access-list LosAngeles permit ip host 217.34.122.3 host 192.168.22.99

HQ ASA

access-list LA permit ip host 192.168.22.99 host 217.34.122.3

- Jouni

John Forester · ‎04-23-2013

Thanks for the response Jouni, however this did not fix the problem. Our other site has only one outside interface, and we are able to send the logs through with no problem (they are both 5510s - and I only see udp 514 on the inside interface of the HQ FW). But for this site they wanted to have an outside interface going straight out for the LA users to hit the web servers there, and then a second outside interface which is tunneled to us at headquarters. This way they can send SIP calls through to headquarters, and they go through with no problems.

I tried both of the methods you have sent, but neither worked. When I check port captures of inside and tunnel interfaces, I do not see any logging from udp 514. If I point to the inside server at LA for logging just to check, the traffic is there on the inside interface. I also tried to permit ip from the inside host 192.168.0.1 to 192.168.22.99 and it did not help.

I am running version 8.4(4) on both firewalls

Jouni Forss · ‎04-23-2013

Hi,

Would it be possible to see the configurations of this ASA5505?

Are you saying that the ASA5505 has 2 ISP connections. Other one for simply Internet traffic and the other to build a L2L VPN with the HQ Site?

- Jouni

John Forester · ‎04-23-2013

Yes,

We have 2 ISP connections going out. One is for the LA area Web users to get to the servers, and the other is our "Tunnel" traffic for maintenance and SIP between sites. Since they are not 24/7, we have had need to shut down the outside interface and remote into the servers to perform restarts at night, plus the benefit of having the SIP traffic go through.

So we have

ethe0/0 - outside

route 0.0.0.0 0.0.0.0 217.34.122.1 - this goes to the ISP for all traffic

ethe0/1 - Tunnel

route Tunnel 192.168.22.0 255.255.255.0 65.29.211.198 - to our HQ firewall, which is our hub for our offsites.

Do you suppose that the route is being preferred over the ACL? When I remove the route Tunnel line, I loose pings from our monitoring station to the servers sitting behind the 5505, but still have not seen traffic change. In fact, when I "clear route" on both ends, I still get the same error when the line is removed.

We are trying to set up a second site the same way, and are seeing the same problem.

I am using version 8.4(4) and CLI - not ASDM - perhaps I should try ASDM to see if it can figure out the problem on its own. I am surprised that this has not happened before, as I can find no reference of this error on the Web or on Cisco's site.

Jouni Forss · ‎04-23-2013

Hi,

I have tested this setup on 8.2 software some months ago, though in that case my ASA had a single ISP link. I used the configured L2L VPN connection to send the local ASAs logs through the L2L VPN and I also used the L2L VPN for SNMP connections.

I checked and found the actual thread about that setup. Heres a link to it

https://supportforums.cisco.com/message/3603117

I was thinking if I could see your ASA5505 configurations I could confirm that its configure the same way I would go about configuring such a setup. Maybe even lab it myself.

At this point it would seem to me that the most important thing would be to confirm that the "logging" configuration says that the Syslog server is found behind "Tunnel" interface and that the IP address of "Tunnel" interface is included in the L2L VPN ACL that defines interesting traffic.

- Jouni

John Forester · ‎04-24-2013

Hi Jouni,

I have the following configs in place with fake IPs

5505

1 outside interface with security level 0 (vlan1 direct connect to isp 217.33.122.2/30) - goes to ISP

1 Tunnel interface with security level 1 (vlan 2 direct connect to isp 217.33.122.6/30) - goes to Tunnel to our 5510

1 inside interface with security level 100 (servers connected to hub, with vlan3 ip of 192.168.0.1)

access-list LosAngeles extended permit ip 192.168.0.0 255.255.255.0 192.168.22.0 255.255.255.0 - acl to 5510 inside network

route outside 0.0.0.0 0.0.0.0 217.33.122.1 - route for all traffic (except for 192.168.22.0/24) to take the outside connection

route Tunnel 192.168.22.0 255.255.255.0 65.29.211.198 - route for 192.168.22.0 destined traffic to take the Tunnel connection

crypto map TO-HQ 10 match address LosAngeles

crypto map TO-HQ 10 set peer ip 65.29.211.198

tunnel-group 65.29.211.198 type ipsec-l2l

5510

1 outside interface with security level 0 (vlan1 direct connect to isp 65.29.211.198) - goes to isp

1 inside interface with security level 100 (vlan2 connection to corporate servers and SIP 192.168.22.0/24)

access-list LA extended permit ip 192.168.22.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list OUTBOUND extended permit icmp host 217.33.122.6 host 192.168.22.99 (allows Nagios monitor to ping the DE interface

access-group OUTBOUND in interface outside

nat (inside,outside) static 192.168.22.99 interface destination static 217.33.122.6

route outside 192.168.0.0 255.255.255.0 217.33.122.6

crypto map TO-LA 20 match address LA

crypto map TO-LA 20 set peer ip 217.33.122.6

tunnel-group 217.33.122.6 type ipsec-l2l

I am mistaken on the 5510 interfaces. They do not have vlans, and the IP address is directly applied to the interfaces for outside and inside.

Jouni Forss · ‎04-24-2013

Hi,

Actually if you have the static route configured on the 2 ISP ASA like this

route Tunnel 192.168.22.0 255.255.255.0 65.29.211.198

I think you need to change it to point to the local ISP gateway IP of the network 217.33.122.6/30, not the L2L VPN peer IP.

- Jouni

John Forester · ‎05-01-2013

Hi Jouni,

Sorry for the late reply. I was down in L.A. and flew back Monday from Orange county.

I changed the route as you suggested and I now see logs leaving the Tunnel interface (udp 514) on the LA firewall, and of course only see ESP 50 coming into the HQ firewall's outside interface. They are coming from the Tunnel VLAN IP of 217.33.122.3 and headed to the server 192.168.22.99 I am now trying to figure out how to get them from the HQ firewall to the inside zone.

I've tried an ACL

access-list permit LA permit udp host 217.33.122.3 host 192.168.22.99 eq 514

But it would not bring the logs to the inside

Do you suppose a nat statement would work?

Thanks for the help

Jouni Forss · ‎05-01-2013

Hi,

I think the situation should simply be so that the remote site ASA is sending logs with its Tunnel WAN IP address as the source. So you should basically make sure that the L2L VPN ACL configurations reflect the situation that the remote site WAN IP needs to reach the HQ networks Syslogs server

You will naturally also need NAT0 configuration from the Syslog server IP towards the remote sites Tunnel WAN interfaces public IP address.

To copy my above posts configurations

Branch ASA

access-list LosAngeles permit ip host 217.34.122.3 host 192.168.22.99

HQ ASA

access-list LA permit ip host 192.168.22.99 host 217.34.122.3

Also add NAT0 configuration for the host 192.168.22.99 towards host 217.34.122.3

- Jouni

John Forester · ‎05-02-2013

Hi Jouni,

I am still unable to get the logs to the inside interface. I put in the following commands:

LA

logging host Tunnel 192.168.22.99

access-list LosAngeles permit ip host 217.34.122.3 host 192.168.22.99

route Tunnel 192.168.22.0 255.255.255.0 217.34.122.1 (next hop)

HQ

access-list LA permit ip host 192.168.22.99 host 217.34.122.3

nat (inside,outside) source static obj-192.168.22.99 interface destination static obj-217.34.122.3 obj-217.34.122.3

Both access-lists are applied at the VPN as "crypto-map TO-HQ 10 match-address LosAngeles" and "crypto-map TO-LA 20 match-address LA"

I am curious on what you think. One thing that I keep thinking is that I cannot use logging host Tunnel 192.168.22.99. It was explained to me that the logging host command must point to the interface that the distant logging host resides on, which would be logging host inside 192.168.22.99. But that brings me back to the original problem. My other curiosity is that the Tunnel interface is security level 1 whereas the other end at HQ is security level 0. I would think the nat statement would solve that problem though, if it was a problem.

Do you see anything else I can try for this?

Thanks again for all of your help.

Jouni Forss · ‎05-02-2013

Hi,

Isnt the host that acts as the Syslog server specifically behind the "Tunnel" interface as that interface forms the L2L VPN connection to the actual HQ site?

I think your NAT configuration isnt correct though

nat (inside,outside) source static obj-192.168.22.99 interface destination static obj-217.34.122.3 obj-217.34.122.3

This doesnt match the interesting ACL configuration

access-list LA permit ip host 192.168.22.99 host 217.34.122.3

The above ACL states that the ASA is expecting traffic between hosts 192.168.22.99 and host 217.34.122.3. However, your NAT configuration is saying that it will NAT the IP address 192.168.22.99 to the HQ ASA "outside" interface IP address

This wont match the L2L VPN rules at all to my understanding.

I think the NAT rule should be

nat (inside,outside) source static obj-192.168.22.99 obj-192.168.22.99 destination static obj-217.34.122.3 obj-217.34.122.3

This NAT rule tells that when host 192.168.22.99 has connections (doesnt matter which host initiates connection) towards the IP address 217.34.122.3 THEN DO NOT DO any kind of NAT for either the source or destination IP address. This would then match the L2L VPN ACL that defines the interesting traffic.

Hope this helps

- Jouni

John Forester · ‎05-06-2013

Hi Jouni,

I input the nat as you suggested, however it did not have the desired effect. For some reason when I put this in, it worked for a bit, then after lunch it stopped the firewall logs from going out of the interface at 217.34.122.3....

It took me a few hours, but I ended up clearing it, and restarting the logging by removing the ACL access-list LosAngeles permit ip host 217.34.122.3 host 192.168.22.99. After this it worked again, although I have not had time to check today yet. Anyway, thank you for the help.

Do you suppose that since I am sending to a private IP address, that it may be getting dropped as it leaves the firewall? I have heard the term "destination nat" but not sure if this would apply.

I you have any other ideas, I would appreciate your thoughts.

Thanks

Ah, now I cannot reach the LA firewall. I can ping the interfaces and even the servers on the inside..... This may be bad as the users there don't even know what it looks like

I did learn a couple things which I will try at my end

1 is to try a clear xlate command locally to see if it becomes reachable.

2 is that I just read that the nat rules are linear, so I will have to check all of them to see if there is something in there before the nat that could cause the problem. this is a version 8.4 change from what I read.

When I ran packet-tracer it made it past the nat to phase 4 which showed the drop reason as acl-drop flow is denied by configured rule - not sure which of the two acls it means though (I have an acl going through the l2l tunnel, and an acl going in the outside interface for pings to nagios).