ASG v6 to v7 - tunnel okay but no data transfer

This behaviour gets especially weird because another ipsec tunnel to another remote endpoint with dynamically assigned ip is working as always... traffic in both directions are okay - so what the heck can that be??
I tried around with compressing, strict routing, MTU sizes (on both sides) but nothing helps...

I would really really appreciate your help!!

Michael

Sounds like either the VPN is not really up (double check the VPN status on both ends) or there is a routing issue.

To verify, both subnets at each end of the VPN are unique?

Hmm.... 172.99.x.x is not in the list of reserved internal IP addresses as defined by RFC 1918:  ftp://ftp.rfc-editor.org/in-notes/rfc1918.txt

I bet your problem is that the systems don't know where to route the packets.  Change that 172.99.x.x subnet to something that falls in the reserved IANA range -- I've seen this problem before with other routing / VPN Setups.  If that doesn't fix it, I don't know what it could be.

Valid Internal IP ranges:
10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

I bet your problem is that the systems don't know where to route the packets.  Change that 172.99.x.x subnet to something that falls in the reserved IANA range -- I've seen this problem before with other routing / VPN Setups.  If that doesn't fix it, I don't know what it could be.

That shouldn't matter. There's nothing keeping you from defining VPNs in public IP space, we do it all the time.

When the VPN is set up, it should route packets to that subnet via the VPN. And as the OP state originally, it used to work, but later stopped, so I suspect that something changed in his configuration that made this happen.

That very well may not be the reason for the problem in this case; however, I have in fact (it's been many moons ago) had customers with network problems, specifically with VPN tunnels and routing, due to public IP ranges being used on private networks.  The devices being used were trying to send packets to the "real" public hosts instead of the private ones.  Changing the subnet to a valid internal one fixed the issue, at least at 2 sites as I recall.  Just something to look at.

Hi BrucekConvergent,

Hmm.... 172.99.x.x is not in the list of reserved internal IP addresses as defined by RFC 1918:  ftp://ftp.rfc-editor.org/in-notes/rfc1918.txt

[...]

Valid Internal IP ranges:
10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

okay, I have to admit that I changed the ip address range from a valid one - for security reasons - to 172.99/16. Believe me that the real network *is* in the range of 172.16/12. I swear!! ;-)

So your approach could be right - but in my case it's not, sorry for the misunderstanding which I lead you into...

Michael

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?

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

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

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?

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

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

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

Glad you got it solved! I wonder why the auto-packet filter rules weren't working...