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

S-2-S IPSec Connects, No PING, No Nothing Else

I upgraded my Home ASG7.502 to V8 two days ago. I had one Site-to-Site IPSec tunnel configured between my old V7.502 and another V7.502 at work. After the upgrade this all worked fine; i.e. the IPSec tunnel between the V7.502 at work and the V8 at home worked perfectly fine.

Today I upgraded the V7.502 at work to V8 also and decided to reconfigure the FW from scratch since there were a lot of obsolete objects created in the previous config that needed to be cleaned out anyway. Setting up the Site-to-site IPSec tunnel to my Home V8 worked fine and the connection was established without problems.

The problem I have is that even though the connection is established I cannot access my office LAN from home or vice versa - no pings work, no RDP or SSH to any servers, no http, no ftp, no nothing . Here are the config details:

Policy:
IKE Encryption algorithm: AES 128
IKE authentication algorithm: SHA1
IKE SA lifetime: 28800
IKE DH Group: Group 2: MODP 1024
IPSec encryption algorithm: AES 128
IPSec authentication algorithm: SHA1
IPSec SA lifetime: 3600
IPSec PFS Group: Group 2: MODP 1024

Connection:
Auto packet filter: ON

Advanced:
Use Dead peer detection: ON
Use NAT traversal: OFF

I verified that the policies are identical on both sides and also that the protected subnets on each side was defined properly (no typos there!).

Network Security -> Packet Filter -> ICMP:
Allow ICMP on firewall: ON
Allow ICMP through firewall: ON

Firewall is Ping visible: OFF
Ping from firewall: ON
Firewall forwards Pings: ON

Firewall is Traceroute visible: OFF
Firewall forwards traceroute: ON

I included a route dump from the fw shell as well as the results of a ping from the shell (which gets an ICMP Destination host unreachable response). I can ping the WAN side IP addresses of both firewalls.

Does anybody have any ideas? [:S]
Any help would be greatly appreciated!


This thread was automatically locked due to age.
  • Just a general question: we normally select 'Use NAT traversal'; what advantage do you get by not?

    You didn't say, but, given the time of your post [;)], I'll guess that 192.168.200.0/24 is your office network, and that 192.168.128.200 is an IP in your home network.  Do you need a route '192.168.128.0/24 -> 192.168.128.200' in your office Astaro?

    Cheers - Bob
  • Thanks for the response BAlfson.
    Yes, you are correct. 192.168.200.0/24 is my office subnet and 128.200 is my PC at home. I have another tunnel up to another of my branch offices and for some reason when I set that up a while ago I did not switch NAT Traversal on so in my troubleshooting last night I switched NAT Traversal off since the working tunnel had it switched off also. But there is no other reasoning beyond that to have had it switched off. However, I tried switching it on on both ends this morning but it made no difference.
  • I attached a route dump from the remote gateway also and it shows a route back to 128.200 

    I have never needed to add any custom routes before; is this a routing bug or something? [:S]
  • I have same Problem since update last weekend.

    Site1: v7.507 / Site2: v8.001

    Site2 was updated to V8 with import of the last config file. Everything looks good, S2S-VPN is up, but no service works (icmp, rdp, vnc, ...)

    I play with routes, nat, packetfilter,...nothing.

    Today i will spent time in setting up a second V8 as Site3 with creating a S2S-VPN to Site2, to see its a problem between v7 and v8.
  • I had the same problem when upgrading a main office to ASG 8 that all the remote locations connected to.

    I didn't have any issues with I upgraded the remote locations to ASG 8 while the main office was still on ASG 7.

    When trying to trouble shoot this I could see the packet filter was "Default Blocking" all packets from every remote site. I added a packet filter to allow all traffic from the remotes to main office (and visa-versa) and the packet filter live log still had "Default Block" with any traffic between the two.

    In the end I changed over to S-2-S SSL (just to get it working again), which isn't ideal (as when you make a change to any of the SSL VPN settings it takes down all the SSL VPN connections).

    Hopefully some of this information is helpful for others to trouble shoot with.
  • When trying to trouble shoot this I could see the packet filter was "Default Blocking" all packets from every remote site. I added a packet filter to allow all traffic from the remotes to main office (and visa-versa) and the packet filter live log still had "Default Block" with any traffic between the two.

    I wonder if you haven't almost isolated a bug...  If you would like to work on that, please show one or more "blocked" lines from the full (not the live) packet filter log, and a pic of the PF rule that should have allowed the traffic.

    Cheers - Bob
  • Good morning,

    i setting up a second system (as site3) on v8, connected to the branchoffice (as site2) which be also a v8. The system in mainoffice (as site1) is on v7.

    In the following picture you can see, that the site2 is successfull connected to both sites, but only in the connection between site3-to-site2 (v8-to-v8) works the services like icmp, rdp,...

    In the connection site1-to-site2 (v7-to-v8) nothing works [:(]

    I used difference policies to test, but nothing helps. Next steps...
  • Hello,

    please try to transfer a very small file (e.g. 500 Bytes) and see if its goes through. Maybe it will work with ping -l 500  as well.
  • Folks, when you want to disguise your IPs, please do so in a way that lets others see what's happening.  Instead of turning 68.78.88.98 into x.x.x.x, use 68.x.x.98 so that it can be identified as public and different from 111.222.33.44 (111.x.x.44).  Likewise, with 192.168.33.1, use 192.168.x.1 instead of 192.x.x.1 so that it's clearly a private IP.

    Synopex, if Stefan's suggestion to check the MTU doesn't solve your problem, you might confirm that you don't have an IP subnet overlap.

    Cheers - Bob
  • Stefan: no, it doesn´t work

    BAlfons(Bob): You are right [:)]

    Site1
    Description: Mainoffice
    Version: v7.507
    LAN: 172.31.x.0/24
    DMZ: 10.10.10.0/24
    WAN: PPPOE with fix IP (213.146.xx.81)

    Site2
    Description: BranchOffice
    Version: v8.001
    LAN: 192.168.x.0/24
    WAN: PPPOE with fix IP (75.92.xx.213)

    Site3
    Description: Test-lab
    Version: v8.001
    LAN: 192.168.10.0/24
    WAN: in DMZ behind Site1 (10.10.10.1)

    IPSec-VPN between Site1/Site2 stop route (not shure routing) after update Site2 to v8. Site1 still v7
    For tests i create a new "virtual" location as site3 in the dmz behind site1. Site3 now also VPN'd to Site2, both systems on v8.

    Fact: no problems with double or overlap subnets,
            no problems with VPN Site2-Site3
            but problem with VPN Site1-Site2

    Unplug Site1's DSL, plug and configure Site3 with this DSL will be my next step for testing.

    servus