Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 2550 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

Tunnel NAT/Packet Filtering 101?

gravyface
I've been experimenting with Site-to-Site VPNs in my test environment.  I have two satellite networks, each behind a SnapGear router/firewall with an IPSec tunnel (IKE/PSK) setup into my Astaro Gateway.  Both tunnels are setup identical; "Auto packet filter is on, not using strict routing".  The Astaro has two interfaces in use: one external/WAN interface on the Internet, the other as 10.0.1.1 on the internal interface.

Astaro Gateway: internal interface: 10.0.1.0/24, external interface/static IP: 50.20.30.40

Satellite One: internal interface:192.168.1.0/24, external interface/static IP: 100.20.30.40

Satellite Two: internal interface:192.168.2.0/24, external interface/static IP: 200.30.40.50 

Tunnels are up, no problem.  

The problem is, from each of the Satellites, I can only ping the internal interface of the Astaro Gateway (10.0.1.1), but none of the other nodes on the internal 10.0.1.0/24 network.  However, if I turn on Masquerading so that Satellite One or Two is masquerading as the Astaro's internal network, I can ping all nodes on the 10.0.1.0/24 network.  For fun, I also setup Remote Access (L2TP VPN with RADIUS) and have experienced the same issue with software-based VPN sessions.

Now what I want to be able to do is only permit a certain host on the 10.0.1.0/24 network (lets say 10.0.1.5) from being accessible by the two satellite internal networks.  With masquerading in effect, I've also tried setting up an allow rule for that host and a deny rule following it for all the other hosts, but that doesn't seem to work either.

I tried setting up packet filtering rules, but the live log doesn't even show the traffic, and it doesn't seem to have taken effect.  I also tried searching through today's packet filtering log and can't even see any hits on the one particular source host (192.168.0.100). 

However, the summary view that's displayed when you click on the Network Security menu item shows "top 10 hosts" and shows that source host's 45 dropped packets.  Strangely, I cannot get this value to increase/decrease no matter how long/how many times I try again (I actually let the source host on the Sat. One network ping 10.0.1.5 for probably 30-40 minutes).  

Now, I'm not certain that I need to masquerade, nor if it's desired/Right Thing (tm).  I'm assuming (with my limited knowledge) that any source traffic will be masqueraded as 10.0.1.0/24 traffic, which would make it difficult/impossible to track particular host activities.

Can someone shed some light on why masquerading is seemingly necessary and/or should I be doing something else?  As I'm posting I'm trying to read up on NAT, packet filtering, etc. (maybe routing too?) as I'm new to all this, obviously.

If you need more details re: my config, please ask.

Thank you in advance


This thread was automatically locked due to age.
Parents
  • 0
    Wait, I just thought of something: the Astaro is just a node on the 10.0.1.0/24 network at the moment; 10.0.1.5's default gateway is a router than knows nothing of the Astaro.  Is there no route back to the tunnel's source host (192.168.0.100) without masquerading?
  • 0 in reply to gravyface
    Wait, I just thought of something: the Astaro is just a node on the 10.0.1.0/24 network at the moment; 10.0.1.5's default gateway is a router than knows nothing of the Astaro.  Is there no route back to the tunnel's source host (192.168.0.100) without masquerading?


    Correct, if the astaro is not the default gateway of 10.0.1.5, you will need to add the route for the remote network to the router or that machine. This would explain why it works with masquerading enabled as the traffic looks like it is coming from the astaro's internal interface and is local to 10.0.1.5.

    If you are trying to restrict traffic over the vpn tunnel, I would suggest disabling the automatic packet filter rules and create your own in the packet filter. The automatic packet filter rules act before the ones you manually create and you will not see this traffic in the packet filter log.
Reply
  • 0 in reply to gravyface
    Wait, I just thought of something: the Astaro is just a node on the 10.0.1.0/24 network at the moment; 10.0.1.5's default gateway is a router than knows nothing of the Astaro.  Is there no route back to the tunnel's source host (192.168.0.100) without masquerading?


    Correct, if the astaro is not the default gateway of 10.0.1.5, you will need to add the route for the remote network to the router or that machine. This would explain why it works with masquerading enabled as the traffic looks like it is coming from the astaro's internal interface and is local to 10.0.1.5.

    If you are trying to restrict traffic over the vpn tunnel, I would suggest disabling the automatic packet filter rules and create your own in the packet filter. The automatic packet filter rules act before the ones you manually create and you will not see this traffic in the packet filter log.
Children
  • 0 in reply to dilandau
    Yup, thanks for confirming my hunch. I'm motoring along now with my rules but I've hit a couple of snags:

    1. Sat. One cannot access Sat. Two because (I'm assuming) there's no route back to One from Two?  I've added an allow rule to permit Sat. One from accessing Sat. Two and I see green packets in the Live Log, but I cannot connect; I even tried connecting to Sat. Two's SnapGear's Web Mgmt Interface, but no luck.  This is actually the behavior I'm after, but obviously I'd like to know why.

    2. Any node on the 10.0.1.0/24 network can access any node on either Sat. One or Sat. Two.  This is not desired.  I thought that the SnapGear would drop all packets on the WAN interface by default -- regardless of tunnel -- but it's not.  I'm going to check out the SnapGear dox as to why, but I'd also like to drop packets from all 10.0.1.0/24 nodes except for one particular host and would like to enforce that in the Astaro's packet filtering rules.  
    My first rule is "Internal (10.0.1.0/24) -> Any" which I'm assuming is allowing access to all the tunnel networks.  My plan was to do something like: 
    #1 "Internal (10.0.1.0/24) -> ALLOW -> Internet"
    #2 "Internal (10.0.1.0/24) -> ALLOW -> Internal (10.0.1.0/24)" 
    #3 "Internal (10.0.1.0/24) -> DROP -> group ('Satellite Locations')"

    but I'm not sure if this is the way to go and/or what to use for "Internet".
  • 0 in reply to gravyface
    Graveyface, I realize that your primary purpose is experinemting with VPNs.  If I understood your first post correctly, the task you were trying was to provide service limited to a single server.   Normally, we would use the following approach for that: How to Port Forward Service Ports (Webservers, RDP, OWA etc..)

    Having said that, I would try defining 'Internet' in your above question as:

    Name: Internet
    Address: 0.0.0.0
    Netmask: 0
    Interface: [whatever your external interface is]



    Anyway, thanks for the interesting questions and the clear explanations of your situation.

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob, thanks for responding.

    I tracked it down to Auto packet filtering being enabled (I thought I had turned that off, but had not), so the first rule is now: 

    #1: Admin Machine (10.0.1.50) -> ALLOW -> Satellite Locations (group)
    #2: Internal Network (10.0.1.0/24) -> DROP -> Satellite Locations (group)
    #3: Internal Network (10.0.1.0/24) -> ALLOW -> ANY

    This has accomplished what I've been going for -- I wanted one machine on the 10.0.1.0/24 network to be able to connect to the various Satellite Location's routers/firewalls.  That seem about right?

    For failsafe security, I'm assuming I should set the various Satellite Locations' firewalls to drop 10.0.1.0/24 packets that do not match 10.0.1.50 as well?