Screen OS

Hi, I'm trying to establish a VPN connection to a third party, but I can not generate traffic and that is why as the in the recipient end of the VPN does not work. His only answer is that we not generates traffic through the tunnel so the connection is not completed.

My SA indicates ACTIVE with state down, and my tunnel interface appears READY.

The connection I have configured several times and no success, I checked all the points and seemingly everything is correct, in politics that I have configured TRUST  to UNTRUST does appear as sent traffic (bytes sent) but ZERO bytes received.

My question is: how I can ensure that traffic is being sent through the tunnel?, all I can see are the statistics of the physical interface but not the tunnel interface. I need to know how I can find these data to ensure to the third party traffic is being sent through the tunnel because I think it is at the other end where they have mistakenly configured same ACL mask some wrong (is a CISCO router), but I can not access your configuration or see his debugs.

Using debug flow basic and with dst-ip 172.18.1.1, all I can see is the following, but I do not know whether it is sufficient to ensure that traffic is being sent through the tunnel interface:

    - My lan trust is 192.168.0.1 in ethernet0/4.4 y and the client is 192.168.0.2
    - My interface tunnel.1 (untrust) numbered is 172.18.2.1 with DIP 172.18.2.2 beacuse the third party need that I do NAT with this lan.
    - Destination: 172.18.1.1, configured the route 172.18.1.0 to go by interface tunnel.1 (0.0.0.0 -> ethernet0/2).

    The VPN is configuring for outgoing for ethernet0/2 (untrust) bind by tunnel.1, the ping is since client ethernet0/4.4 (trust) (the SA is ACTIVE and my interface tunnel is READY with phase 2 completed) to 172.18.1.1 that accept ICMP traffic.

Attached file with debugging basic flow-ip dst 172.18.1.1 if it is sufficient to show that the traffic is being sent through the tunnel. I've never seen any error, packet drop, etc..

Any ideas? greetings

Attachment(s)

DebugFlowBasic_TO_172-18-1-1.txt   3 KB 1 version

Hi,

In most cases it is sufficient to enable logging on the policy, both for the session begin and for the session end. You can use "ping 172.18.1.1 from eth0/4.4" to generate traffic if you have no access to the client. A policy should exist that allows this and performs the src-NAT to the DIP. If the session start is logged and it's end logged with the message "Aged out", the problem is on the remote site or ping is blocked, also on the remote GW. The packet had been correctly sent but no response has been received. Sure, you should check if the route to the tunnel interface is up (marked with *) before starting the test. I also recommend to configure a second route for this destination with a higher metric and null-interface as it's route interface. This will drop the packets if VPN failed without sending them along the default route.

If the target host is pingable you can activate VPN Monitor with the option "Rekey". Select eth0/4.4 as source interface and the target ip as a destination. A policy should be configured that nats the 192.168.0.1 to the DIP, because 172.18.2.2 is used in the ACL on Cisco and Proxy ID on Juniper. VPN Monitor gives you a guarantee that the packets are permanently sent into the tunnel and also keeps VPN alive. Further, VPN Monitor detects very fast a VPN failure and deactivate the tunnel route.

You debugging output confirms that the packets are encrypted. But it is cut at the most interesting place. The next packet should be one containing gateway IPs as it's source and destination IPs.

Generally an additional DIP is not required for this configuration. You might have configured the src-NAT to the egress interface.  This is tun.1 IP for the VPN traffic.

Hello, actually the reason for closing is CLOSE - AGE OUT, the policy exists, the route for network 172.18.1.0 is in the routing table to the tunnel.1 interface and one with a higher metric to the null interface. When I try to ping from a client or directly from the console by PING 172.18.1.1 FROM ETHERNET04 / 4, the result is the same, I see in the log of traffic but does not go anywhere.

By checking the MONITOR VPN tunnel interface goes on to state UP, and SA ACTIVE and UP, but after a few minutes closes the connection and try again. In detail ike debug log when I enable this option does not show up any errors or dropped packets, etc, or something that indicates any anomaly.

If that test to confirm that I am actually sending traffic through the tunnel would be enough for me then, indeed, do not know why missing the following lines, where are my public gateway and public gateway, another log to confirm generaré .

Is there any way anyway to somehow get the bytes sent over the tunnel interface (counters flow only phisical interfaces)? There may be some reason why my firewall can not create VPN connections?

thank you very much

it's solved, the third party erased the configuration and reconfigured the VPN connection again and it works, I am convinced that some of his CISCO ACL were denied me traffic.

Thanks for the clarification and make me sure that traffic was being sent through the tunnel interace as I thought.

a greeting,