cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to the Cisco Small Business Community

Have a question? Click on a topic board below to get started in the community.

1176
Views
0
Helpful
7
Replies
hanyelbelqasy
Beginner

VPN PRoblem

Dears

I have Ipsec VPN betwen cisco ADAL router and SA540 FW the IPSEC is up between the two devices but both LANs can not ping to each other only the FW can ping to the remote LAN , but the local lAN can not ping to the remote and the remote can not ping to the local , so kindly your support

the diagramm as attached

7 REPLIES 7
jurodri3
Beginner

Hello Hanyelbelqasy,

We are glad to help you, just a couple of questions.

What was the default gateway set to use at client when VPN tunnel be established ?

was it still able it access its local network?

Also If you could send us some screenshots of the current configuration?

That would help us with the troubleshooting.

Thank you.

In the mean while let me share with you some troubleshooting steps that could help you.

  • Verify that packet filtering on a router      interface between the VPN client and the VPN server is not      preventing the forwarding of tunneling protocol traffic.
    On a      Windows 2000–based VPN server, IP packet filtering can be      configured from the advanced TCP/IP properties and from the Routing      and Remote Access snap-in. Check both places for filters that might      be excluding VPN connection traffic.

  • For remote access VPNs, verify the IP address      pools of the VPN server.
    If the VPN server is configured to use      a static IP address pool, verify that the routes to the range of      addresses defined by the static IP address pools are reachable by      the hosts and routers of the intranet. If not, then IP route      consisting of the VPN server static IP address pools, as defined by      the IP address and mask of the range, must be added to the routers      of the intranet or enable the routing protocol of your routed      infrastructure on the VPN server. If the routes to the remote access      VPN client subnets are not present, remote access VPN clients cannot      receive traffic from locations on the intranet. Routes for the      subnets are implemented either through static routing entries or      through a routing protocol, such as Open Shortest Path First (OSPF)      or Routing Information Protocol (RIP).
    If the VPN server is      configured to use DHCP for IP address allocation and no DHCP server      is available, the VPN server assigns addresses from the Automatic      Private IP Addressing (APIPA) address range from 169.254.0.1 through      169.254.255.254. Allocating APIPA addresses for remote access      clients works only if the network to which the VPN server is      attached is also using APIPA addresses.
    If the VPN server is      using APIPA addresses when a DHCP server is available, verify that      the proper adapter is selected from which to obtain DHCP-allocated      IP addresses. By default, the VPN server randomly chooses the      adapter to use to obtain IP addresses through DHCP. If there is more      than one LAN adapter, then the Routing and Remote Access service may      choose a LAN adapter for which there is no DHCP server available.      You can manually choose a LAN adapter from the
    IP tab on the properties of a remote access server in the Routing and      Remote Access snap-in.
    If the static IP address pools are a      range of IP addresses that are a subset of the range of IP addresses      for the network to which the VPN server is attached, verify that the      range of IP addresses in the static IP address pool are not assigned      to other TCP/IP nodes, either through static configuration or      through DHCP.

  • For router-to router VPN connections, verify      that there are routes on both sides of the router-to-router VPN      connection that support the two-way exchange of traffic.
    Unlike      a remote access VPN connection, a router-to-router VPN connection      does not automatically create a default route. You need to create      routes on both sides of the router-to-router VPN connection so that      traffic can be routed to and from the other side of the      router-to-router VPN connection.
    You can manually add static      routes to the routing table, or you can add static routes through      routing protocols. For persistent VPN connections, you can enable      Open Shortest Path First (OSPF) or Routing Information Protocol      (RIP) across the VPN connection. For on-demand VPN connections, you      can automatically update routes through an auto-static RIP update.

  • For two-way initiated router-to-router VPN      connections, verify that the router-to-router VPN connection is not      interpreted by the VPN server as a remote access connection.
    If      the user name of the calling router's credentials appears under
    Remote Access Clients in the Routing and Remote Access snap-in, the VPN server has      interpreted the calling router as a remote access client. Verify      that the user name in the calling router's credentials matches the      name of a demand-dial interface on the VPN server.

  • For one-way initiated router-to-router VPN      connections, verify that the routes of the calling router's intranet      are configured as static routes on the dial-in properties of the      user account used by the calling router.

  • Verify that there are no TCP/IP packet filters      on the profile properties of the remote access policy being used by      the VPN connection configured on the VPN server (or the RADIUS      server if Internet Authentication Service is used) that are      preventing the sending or receiving of TCP/IP traffic.

  • For demand-dial VPN connections, verify that      there are no packet filters on the demand-dial interfaces of the      calling router and answering router that prevent the sending or      receiving of traffic.

I hope you find this answer useful, if it was satisfactory  for you, please mark the question as Answered.

Diego Rodriguez

Cisco network engineer

Thank you

Dear Juan

thanks you for your reply , but now the scinario changed as I failed to solve it and the service affected , so I configured the VPN beteem the routers and open some policies on the FW , but now the HQ branch can ping to the servers in the remote branch , but remote branches can not ping or reah the HQ servers ,and attaches secreen shot from teh FW policies and after trace from the remote site to any internal IP to the HQ , it reaches only to the FW

note: HQ  internal IPs : 10.1.0.0/16 and the remote site is 10.2.0.0/16

TRACE Result

Jeddah-branch#traceroute 10.1.1.5

Type escape sequence to abort.
Tracing the route to 10.1.1.5

  1 192.168.20.2 128 msec 172 msec 156 msec
  2 78.93.232.210 164 msec 176 msec 152 msec
  3  *  *  *
  4  *  *
  5  *

so I think it needs exemit or identity nat but I don not know haw to do it on the FW

so plz need your support

Thanks

Hello Hanyelbelqasy,

In that case is correct, you are going to use nat to translate the traffic that go out of the lan.

Let me share with you an example taken from the Guide me section, that shows the process step by step.

I hope is useful for you,

http://sbkb.cisco.com/CiscoSB/ukp.aspx?vw=1&docid=c695db9e4aca470886d90aa13c5f1508_Configure_One_To_One_NAT_on_SA_00_Series_Security_Appliances.xml&pid=4&fcid=&fpid=&slnid=5

Diego Rodriguez

Cisco network engineer

Thank you

Dear Juan

I tried to access the link , but I found this message

Restricted Article Access Denied document id:c695db9e4aca470886d90aa13c5f1508_Configure_One_To_One_NAT_on_SA_00_Series_Security_Appliances.xml

plz support

thanks in advance

Hi,

I am sorry for the inconvenience, I just checked and it seems that there is an issue with the site. But In that case I will copy the information here:

Step 1. In the security appliance configuration utility of SA540 device, choose Networking > WAN > IPv4 Config. The IPv4 page is used to configure the IP Address of the SA540 device.

Step 2. In the IPv4 WAN Configuration page, scroll down to the Internet (IP) Address section and choose Use Static IP Address from the drop-down list of IP Address Source.

Step 3. Enter the IP Address provided by the ISP in the IP Address field. For this scenario we use IP Address, 198.51.100.43. This IP Address will be different for different scenarios.

Step 4. Enter the IP Subnet Mask in the IP Subnet Mask field. For this scenario, since the Static IP Address is of Class C, mask 255.255.255.0 is entered.

Step 5. Enter the IP Address of the modem that is connected to the Internet Service Provider (ISP) in the Gateway IP Address field. For this scenario the IP Address is 198.51.100.1.

Step 6. Click Apply to save the configuration.

Step 7. From the left navigation menu choose WAN > IP Alias so that the IP Addresses received from the Internet Service Provider (ISP) can be added here.

Step 8. In the IP Aliases page, click Add to add a static IP address assigned by the ISP. A new window of IP Aliases comes up.

Step 9. In the IP Alias window, enter the IP Address assigned by the ISP in the IP Address field.

Step 10. Enter the subnet mask in the Subnet Mask field.

Step 11. Click Apply to save the configuration.

Note:  Perform steps 8,9,10, and 11 for all the public IP Address and mask given by the ISP.

Step 12. Choose Firewall from the menu bar and choose Firewall > IPv4 Rules from the left navigation menu.

Step 13. In the IPv4 Rules page, click Add to add a IPv4 rule for each public IP Address to associate it with the internal IP Address.

Note: You have to create an outbound rule and an inbound rule.

Outbound Rule

Outbound rule is created for the traffic originating from the internal local LAN to the public WAN. This rule is configured so the packets coming from internal LAN network destined for the unsecured internet knows what IP Address to map to before going out to the internet. This is done to secure the internal network. If the packets go out to the internet with the IP Address of the internal network, it can cause harmful attacks from unsecured internet.

Step 1. In the IPv4 Firewall Rules page, under Firewall Rule Configuration choose, SECURE (LAN) from the drop-down list of From Zone field. This means that this rule is valid for all the traffic generated from the secure LAN.

Step 2. Choose, UNSECURE (Dedicated WAN/Optional WAN) from the drop-down list of To Zone field. This means that this rule is valid for all the traffic going to the secure LAN.

Step 3. Choose, ANY from the drop-down list of Service field if all the services needs to be enforced by this rule.

Step 4. Choose, ALLOW always from the drop-down list of Action field to allow the traffic to flow from the LAN to the WAN.

Step 5. Choose Single Address from the drop-down list of Action field to allow the traffic to flow from the LAN to the WAN.

Step 6. Enter the IP Address of one of the LAN address in the From field for one to one map to a dedicated WAN Address.

Step 7. Choose Any from the drop-down list of Destination Hosts to allow all the traffic coming from the Secure LAN to go out through the WAN.

Step 8. Choose Single Address from the drop-down list of External IP Address under Source NAT Settings. This is done so that the LAN Address can be mapped to a single dedicated WAN Address.