Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 1 subscriber
  • Views 5308 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASG v6 to v7 - tunnel okay but no data transfer

tuxi
Hi,

I'm experiencing a weird problem in getting v6 and v7 together in a site-to-site vpn.
The tunnel is up and okay, ISAKMP sa is good and IPsec sa is also good (v6 says so).

When I try to ping an alive host on the v7 net, I don't get an answer (timeout). Other way same problem.

I played around with the MTU sizes, but they were okay with 1452 or 1420.

The really weird thing is that it worked a few days ago and the next day it stopped working. v6 side with static IPs, v7 with dynamic IP...

Some ideas on what that could be??

Michael


This thread was automatically locked due to age.
  • 0 in reply to tuxi
    Well, that clears that up... have you restarted both systems on both ends of the tunnel?  Did this start after a recent update on either one?

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Hi,

    Well, that clears that up... have you restarted both systems on both ends of the tunnel?  Did this start after a recent update on either one?


    Yes, as stated above, both systems were restarted. Not only the VPN, also the whole server...
    I would have to lie if I would say I know if that happened *after* an update - because as I said above, it worked after creating the tunnel, but I have no idea if I made the update from 7.007 to 7.008+7.009 after creating the tunnel or before... sorry...
    But it may be that this 7.009 update had an impact... I just don't know...

    In the KB I saw a document regarding a problem with 3com network cards, but I don't think this applies to me, because I have another working VPN from the static v6 side to another dynamic ip endpoint with a netgear vpn-router as the endpoint (also site2site vpn) which is running absolutely perfect...

    Michael
  • 0 in reply to drees
    Hi drees,

    sorry for answering so late, I had some other things to do (private).

    Yep, looks OK.

    Your VPN subnets are fine. I am asking if you have any other subnets in those ranges on either firewall for any particular reason.

    Had to ask. [:)]

    When you ping the remote subnet from the other, do you see the packet counts climbing for the VPN when watching the VPN Routes page?

    Do you have strict routing on/off and what about the auto packet filter? If the auto packet filter is off, do you have the appropriate packet filter rules set (though this shouldn't be affecting pings unless you disabled all the ping settings).


    1. no other subnets in those ranges
    2. packet counter are climbing at the vpn status page on v6 side, don't know how to get this information on v7 side...
    3. I tried strict routing on and off, no affect...
    4. firewall rules are auto on both sides
    5. icmp and traceroute - everything turned on - on both sides

    Michael
  • 0 in reply to tuxi
    2. packet counter are climbing at the vpn status page on v6 side, don't know how to get this information on v7 side...

    Do they climb when you ping from both sides of the VPN?

    Also, if you have a TCP port you can connect to on each end, can you attempt to connect to it, then use netstat to figure out if the remote end got the TCP syn packets or not?

    This sounds like a DNAT or SNAT problem to me. Can you post your NAT rules?
  • 0 in reply to drees
    Hi drees,

    Do they climb when you ping from both sides of the VPN?


    sorry to tell you, but I can't test that at the moment. Pinging the other network via the VPN with the ASG seems to be impossible, it doesn't work with the ASG. But with a client from the 172.16/23 net the packet counter on v6 side climbs up.

    Also, if you have a TCP port you can connect to on each end, can you attempt to connect to it, then use netstat to figure out if the remote end got the TCP syn packets or not?


    At the other end (172.99/16) I have several open ports on several servers, I can't reach one of them. As I said above I can't test at the 172.99/16 site live and local at the moment, so I can't tell you if syn packets arrive there or not. But I don't believe that packets arrive there...


    This sounds like a DNAT or SNAT problem to me. Can you post your NAT rules?


    On v7 side there are following DNAT rules specified to reach an internal server on the 172.99/16 net from the outside:

    - from ANY (port 80) to 172.99.1.1 (port 80)
    - from ANY (port 443) to 172.99.1.1 (port 443)
    - from ANY (port 8001) to 172.99.1.1 (port 8001)
    - from ANY (port 25) to 172.99.1.1 (port 25)
    - from ANY (port 110) to 172.99.1.1 (port 110)

    Additionally some SNAT rules (also for icmp echo replies from internal lan to any outside), but correctly configured an only from some clients from the internal network. Nothing strange.

    On v6 side there are only some minor SNAT rules, as well as a rule for allowing/NATing icmp echo replies.

    Michael
  • 0 in reply to tuxi
    Okay, I got it to work now. I had to insert the packet filter rules manually, regardless of the auto-packet-configuration in the ipsec definition.
    Afterwards I had a minor MTU size problem, but this was solved quick.
    Thank you very much for all of your help, I appreciate it very much!!

    Michael
  • 0 in reply to tuxi
    Glad you got it solved! I wonder why the auto-packet filter rules weren't working...
Cookie Information Banner