Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 1053 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

site2site vpn

asgnewbie
hello fellas,

I have two sites both running on asg utm fw
I setup the site2site vpn, the tunnel is up but I cant ping each network

HQ ASG 425 internal ip add is 192.168.0.1/24 connected to layer 3 switch with ip add of 192.168.0.254/24.L3 switch the default gw is asg425 int add 192.168.0.1.L3 switch has lots of switch port vlan interfaces.lets say vlan 192.168.2.1, vlan 192.168.15.1, vlan 192.168.8.1 and etc...All vlans passes through asg w/o a problem they can surf the net.I have gateway route (192.168.0.254) to my asg425. Each vlans has Masquerading and Packet filter under asg425

On other hand I have asg120 on remote site.
Basic setup External and Int addresses are configured properly.
dgw, dns,masquerading and Pf are configured.
In short in this setup everything work fines.No vlans involved on this site.
Again, site2site vpn tunnel is up, but when I tried to ping on HQ side no reply at all.

In the ipsec config below what do I miss?

Any help is welcome


IPSEC Settings for HQ

Remote Gateways
Name =to Remote (115.85.x.x)
Gateway Type= Initiate Conn.
Gateway=Public add of Remote FW
Autentication=Preshared Key
Remote Net=192.168.0.0/24

IPsec Conn
Name=HQ (119.111.x.x)
Remote GW= to Remote (name created in remote gw)
Local interface=External/WAN
Policy=AES-256
Local net =(192.168.8.0/24) part of vlans
           (192.168.8.0/24)  part of vlans
Auto Packet Filter is enabled



IPSEC Settings for Remote
Remote Gateways
Name =to HQ
Gateway Type= Initiate Conn.
Gateway=Public add of HQ FW
Autentication=Preshared Key
Remote Net=192.168.8.0/24 
           192.168.15.0/24

IPsec Conn
Name=Remote
Remote GW=to HQ (name created in remote gw)
Local interface=External/WAN
Policy=AES-256
Local net =internal net (192.168.0.0/24)
Auto Packet Filter is enabled


This thread was automatically locked due to age.
  • 0
    Hmm, if i understand right, the problem is that you cannot ping the remote net from your HQ LAN. You want to connect local vlans 192.168.8.0/24 and 192.168.15.0/24 with your remote office ?
    But it looks like you are using 192.168.0.0/24 in your local HQ and also in your remote office. Is that correct or am i misunderstanding something ?
    If that is correct then you need to configure another subnet in your remote office.

    >> HQ ASG 425 internal ip add is 192.168.0.1/24

    >> IPsec Conn
    >> Name=Remote
    >> Remote GW=to HQ (name created in remote gw)
    >> Local interface=External/WAN
    >> Policy=AES-256
    >> Local net =internal net (192.168.0.0/24)
    >> Auto Packet Filter is enabled
  • 0 in reply to KKnecht
    yeah, you are correct both sites running on 192.168.0.0/24 network.
    but on the Remote Site I want to call the network .8.0 and .15.0 network from HQ net.

    Im just clarifying this kind of setup whether it is a possible or not.

    I cannot change easily the ip address in any site due to there are machines running on special applications.let say one machine running on 192.168.0.3 and the rest of the machines calls this ip add 0.3 just to ran their program accordingly.
  • 0
    Let's take this opportunity to use asgnewbie's unfortunate situation to emphasize the importance of never using 192.168.x.y for businesses.  Even if you don't have a conflict in a site-to-site situation like he does, you're almost certain to have conflicts with individual users doing remote access from home.

    Always use subnets in 172.16.0.0/12 or 10.0.0.0/8.

    but on the Remote Site I want to call the network .8.0 and .15.0 network from HQ net.

    Your problem isn't solved by that.  The remote site also needs to see the HQ as something other than .0.0.  Astaro doesn't offer a 1-to-1 NAT setting, so, if you don't fix this subnet assignment problem, you're stuck with creating additional addresses and NAT rules for each individual resource that should be reachable from the other side.

    Cheers - Bob
  • 0 in reply to BAlfson
    thanks for the clear info balfson