Guest User!

You are not Sophos Staff.

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

IPSec S2S - Need to route internet traffic out far side of the VPN for one subnet

Hi, all...

Long subject; apologies.

Facts:

ASG v8 on both sides of the connection
IPSec VPN / RSA keys
Multiple internal nets on each side of the VPN

Problem:

Need to route traffic from one internal net on one side of the VPN to the internet out the public IP on the other side of the VPN.

Example:

Side A:

192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
zzz.zzz.zzz.zzz (public IP)

Side B:

10.10.10.0/24
10.10.11.0/24
10.10.12.0/24
yyy.yyy.yyy.yyy (public IP)

I need internet-bound traffic from 192.168.1.0/24 to "originate" from yyy.yyy.yyy.yyy.

I've tried a number of masq & SNAT rules, as well as some other tricks, but I can't quite get it. I get the traffic to the far side of the VPN (easy part), but can't get it routed out from there (just ping & traceroute for now; I'll deal with web proxy later).

TIA


This thread was automatically locked due to age.
  • Hi, Lewis,

    If I've understood what you need, no routing and (maybe) no NATs are required, just two separate connections:

    First Connection

    Side A: 

    Remote Networks:

    10.10.10.0/24
    10.10.11.0/24
    10.10.12.0/24
    Internet


    Local Networks:

    192.168.1.0/24


    Side B:

    Remote Networks:

    192.168.1.0/24


    Local Networks:

    10.10.10.0/24
    10.10.11.0/24
    10.10.12.0/24
    Internet



    Second Connection:

    Side A: 

    Remote Networks:

    10.10.10.0/24
    10.10.11.0/24
    10.10.12.0/24


    Local Networks:

    192.168.0.0/24
    192.168.2.0/24


    Side B:

    Remote Networks:

    192.168.0.0/24
    192.168.2.0/24


    Local Networks:

    10.10.10.0/24
    10.10.11.0/24
    10.10.12.0/24



    Now, add 192.168.1.0/24 to 'Allowed networks' for the HTTP Proxy in Side B.  If you aren't using the proxy, just masq 192.168.1.0/24 out Side B's yyy.yyy.yyy.yyy and add the appropriate firewall rules.

    Is that what you were looking for?

    Cheers - Bob
  • Thanks, Bob, but...

    I need only the traffic from one of the Side A networks routed to the internet from Side B. If I were to add internet to the list of protected networks, then every LAN on Side A would push internet-bound traffic across the VPN, correct?
  • That's what I get for speed-reading past important details!  Two IPsec Connections and two Remote Gateways on each side.  I've corrected my post above.

    Cheers - Bob
  • Ah!!!!!!

    Now, I get it. Of course!

    I was still trying to figure out how we were going to keep the rest of the nets on Side A routing out that broadband connection. How elegant! Let me test this and see if it works like the way it looks.

    Thanks so very, very much, Bob. I'll be in touch!
  • Wow! Indeed, that was it. Thanks again, Bob.

    Now, what's left is to deal with the "spillage." I can't seem to firewall the traffic coming from the subnet in question from the other Side B local LANs, i.e., traffic from 192.168.1.0/24 now properly "originates" on the internet from yyy.yyy.yyy.yyy (Side B public interface), but the final piece of the puzzle is to keep someone on 192.168.1.0/24 from reaching someone on 10.10.10.0/24. I've tried adding drop rules on both sides, but I'm still not able to stop the traffic from hitting that far side, private LAN. Any thoughts on this part?
  • You have to remove 10.10.10.0/24 from the first connection.  Any Firewall rules you make will be considered after the automatic ones created for the VPN have already allowed the traffic, so, just like the routes weren't helping before, Firewall rules can't help now.

    Once you see it, it will be simple - just as any traffic not explicitly allowed through a firewall will be blocked, traffic not explicitly connected by the VPN will not go through the tunnel.

    This also goes back to the basic concept that "DNATs come before Proxies and VPNs come before manual firewall rules and routes."

    Cheers - Bob