palo alto azure VPN issues

Had some issues with palo alto <> azure VPN. The firewall was blocking the VPN traffic due to rule change. Azure gives up after a while and goes into idle mode. Needs to be restarted on azure end

 1 - If Azure VPN starts getting blocked by the firewall after some time Azure gives up and goes into an idle mode, has to be restarted on Azure end for VPN to try again.

2 - The ISAKMP (udp 500) session stays open on the palo even through p1 re-keys. Check session browser for your peer IP on UDP port 500, may need to clear it.

clear session all filter destination x.x.x.x

clear session all filter source x.x.x.x

3 - Related to above if the rule that allows the UDP is set to log at end you won't see the new traffic being initiated, set the rule to log at start.

4 - We saw the Azure IP is showing with a geolocation IP of "EU"  I'm guessing its related to their HA

show location ip x.x.x.x

Azure to Cisco Firepower FTD S2S VPN issues

The issue

Azure’s IKEv1 VPN is “policy based” by default (crypto map)

Azure’s IKEv2 VPN is “route based” by default (VTI / tunnel interface / routes)

Cisco FTD side IKEv2 VPN is “policy based” (crypto map)

My FTD was running version 6.6.1 which doesn’t support the VTI interfaces needed for route based VPN. VTI support is added in version 6.7 but that version also requires 32GB of RAM and it also deletes old DH groups liks DH group 2. All 3rd parties would need to be contacted. All S2S VPN’s with 3rd parties would need to be updated. That is a significant amount of work that would need to be co-ordinated and would need sign off and OOH work etc.

Why it works sometimes

When Azure side is trying to initiate the traffic. It’s trying to use IKEv2 route based which won’t work. However when the lifetime is reached and the VPN re-keys if the Cisco side initiates the traffic with IKEv2 policy based the azure side will accept that connection. That is why it works sometimes and does not work other times. It just depends on which side tries to bring the VPN up first after it has gone down from lifetime expiry.

Some possible fixes:

1 – Change the VPN to the old IKEv1 policy based VPN. This should work but might have implications for security audits etc. 

2 – Change azure side to be policy based, and responder only. Cisco TAC said there is a checkbox to make the VPN policy based and responder only. Azure side will need to go into powershell and manually add traffic selectors

The TAC engineer said a support ticket with Azure may be required to set this up. 

Cisco side will need to setup a script to constantly ping something on the Azure side. This will keep the Cisco side initiating the VPN.

3 – Upgrade Firepower to 6.7. May need RAM upgrade. Will need to contact all 3rd parties which have a site to side and co-ordinate updating all the VPN settings.

Possible quick fix/work around:

Setup the ping –t from the Cisco side to the azure side

Clear down the VPNs (affects all S2S VPN’s)

Do this a few times until we can bring the VPN between Azure <-> DLR backup with DLR side as initiator

Daniel can you give me a host to ping on the Azure side (10.5.0.0 255.255.255.0), I don’t think it even needs to respond but just something I can use to generate traffic to match the VPN.

cisco asa debug commands for S2S vpn

Set the debug on just your peer

debug crypto condition peer x.x.x.x

Ikev1 / ipsec

debug crypto ikev1 255

debug crypto ipsec 255

ikev2

debug crypto ikev2 protocol 127
debug crypto ikev2 platform 127

Debug crypto ikev2 255

Debug crypto ikev2 platform 255

Debug crypto ikev2 protocol 255

If you need more detail you can enable more

Debug crypto ipsec 255

Debug crypto ike-common 10

Debug crypto engine 255 (causes too much output)

logging console debugging

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113574-tg-asa-ipsec-ike-debugs-main-00.html#anc6

IKEv2 Notes

IKEv1 had clear phase 1 (ikev1) and phase 2 (ipsec).

IKEv2 does it all in one phase but broken into 3 sections:

IKE_SA_INIT

IKE_AUTH

CHILD_SA

setup syslog on cisco ASA

Syslog is UDP traffic on port 514

The ASA will send traffic on its own IP address from SRC port 514 to dst server IP and port 514

192.168.1.254.514 > 192.168.1.100.514:  udp 201

Usual config to enable
logging enable
logging timestamp
logging trap debugging

logging facility 23

logging device-id ipaddress inside system
logging host INSIDE x.x.x.x

no logging hide username

For FMC flex config drop the g for some reason "no loggin hide username"

Syslog over S2S VPN

First make sure the VPN is up and working

logging enable

logging timestamp

logging trap debugging

logging asdm debugging

logging device-id ipaddress inside

logging device-id ipaddress inside system (system  Specifies to use the cluster system IP address of the interface to present an integrated view for all units)

Logging host can differ not sure why

logging host inside 10.36.0.200

logging host outside 10.36.0.200 (some cases I had to use outside ASA v8.2)

You will get a warning (because route is to outside) but it will work

WARNING:  configured logging host interface conflicts with route table entry

You also need to have management access configured like so

management-access inside

Set route

route outside 10.36.0.200 255.255.255.255 100.100.200.200 1

Good idea to make sure you allow ssh on the outside (public IP) and inside (LAN IP) so you can SSH in and check/change settings

ssh 180.100.100.100 255.255.255.255 outside

ssh 192.168.200.200 255.255.255.255 inside

Permit host down

logging permit-hostdown

More detail

Examples:

logging host dmz1 192.168.1.5 udp 1026 format emblem

The format emblem keyword enables EMBLEM format logging for the syslog server with UDP only. The interface_name argument specifies the interface through which you access the syslog server. The syslog_ip argument specifies the IP address of the syslog server. The tcp[/ port ] or udp[/ port ] keyword and argument pair specify that the ASA and ASASM should use TCP or UDP to send syslog messages to the syslog server.

You can configure the ASA to send data to a syslog server using either UDP or TCP, but not both. The default protocol is UDP if you do not specify a protocol.

If you specify TCP, the ASA discover when the syslog server fails and as a security protection, new connections through the ASA are blocked. To allow new connections regardless of connectivity to a TCP syslog server, see Step 3. If you specify UDP, the ASA continue to allow new connections whether or not the syslog server is operational. Valid port values for either protocol are 1025 through 65535. The default UDP port is 514. The default TCP port is 1470.

logging trap debugging

Specifies which syslog messages should be sent to the syslog server. You can specify the severity level number (1 through 7) or name. For example, if you set the severity level to 3, then the ASA send syslog messages for severity levels 3, 2, and 1. You can specify a custom message list that identifies the syslog messages to send to the syslog server.

logging permit-hostdown

(Optional)  If you negate this command and syslog server goes down then traffic stops flowing

logging facility 23

(Optional) Sets the logging facility to a value other than 20, which is what most UNIX systems expect.

logging buffered

Specifies which syslog messages should be sent to the internal log buffer, which serves as a temporary storage location. New messages are appended to the end of the list. When the buffer is full, that is, when the buffer wraps, old messages are overwritten as new messages are generated, unless you configure the ASA to save the full buffer to another location. To empty the internal log buffer, enter the clear logging buffer command.

logging buffer-size 16384

Changes the size of the internal log buffer. The buffer size is 4 KB.

logging savelog latest-logfile.txt

Saves the current log buffer content to the internal flash memory.

logging asdm debugging

logging console debugging

Specifies which syslog messages should be sent to the console port.

logging monitor debugging

Specifies which syslog messages should be sent to a Telnet or SSH session.

terminal monitor

Enables logging to the current session only. If you log out and then log in again, you need to reenter this command. To disable logging to the current session, enter the terminal no monitor command.

logging standby

send logs from the standby ASA as well

logging list

More here:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/monitor_syslog.html

ASA to SSG VPN setup

https://blog.webernetz.net/2014/01/28/ipsec-site-to-site-vpn-juniper-screenos-cisco-asa/