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

VPN passthrough problems with new deployment

Hiltonmagk
Really having some problems with my recent deployment of my UTM.  My UTM is my gateway router/firewall and my IPSec VPN device sits in my DMZ.  I've read where you need to add rules to the UTM to get the IPSec traffic to pass though the UTM but the rules aren't working completely.  I've got 8 VPNs that need through so I created host definitions for the public IP addresses of the endpoints and put them in a group.  I then created a rule that allows IPSec traffic from the external IP address to the host definition of the DMZ IP address of the IPSec VPN device.  The IPSec traffic is the predefined service group on the UTM.  When I do that 5 of my VPNs come up but the other 3 do not.  I clearly see blocked IPSec traffic in the firewall log that shouldn't be getting block per the rule.  So I create a rule for the traffic I see getting blocked and allow it.  Which I don't think I should have to do but I did anyway to try and get the VPN up.  I stop seeing the traffic getting blocked but I'm not seeing the traffic get to the VPN device either.  After hours of troubleshooting I finally had to revert back to my old setup to bring all the VPNs up.  I'm basically just creating another level of security with this router as the VPN device is/was my gateway router now.  The Sophos interface seems pretty easy to configure but only if it does what you think it should be doing. 

Here's an example from the firewall log

2015:06:11-00:38:18 pgate ulogd[4569]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="0:b0:4a[:D]2:ab:1c" dstmac="0:a:cd:1e:ed:0f" srcip="69.x.x.x" dstip="68.x.x.x" proto="17" length="132" tos="0x00" prec="0x00" ttl="60" srcport="500" dstport="500" 

2015:06:11-14:56:49 pgate ulogd[14564]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62011" initf="eth1" srcmac="0:b0:4a[:D]2:ab:1c" dstmac="0:a:cd:1e:ed:0f" srcip="69.x.x.x" dstip="68.x.x.x" proto="17" length="208" tos="0x00" prec="0x00" ttl="60" srcport="500" dstport="500" 

69.x.x.x is the remote endpoint and 68.x.x.x is the local endpoint.


This thread was automatically locked due to age.
Parents
  • 0
    Hi, and welcome to the User BB!

    Was the VPN server on the edge before?  It appears that IPsec may have an issue with NAT.  The first line is a block out of the INPUT chain because the UTM had no reason to accept a packet sent directly to it.  The second line is a logging of a similar packet by NAT rule #11.

    To fix this, the remote endpoint must know the internal IP of your VPN server or it must be in the equivalent of "Respond only" in WebAdmin.  If that has been done, then it seems likely that the Host definition for the VPN server violates #3 in Rulz.

    Cheers - Bob
Reply
  • 0
    Hi, and welcome to the User BB!

    Was the VPN server on the edge before?  It appears that IPsec may have an issue with NAT.  The first line is a block out of the INPUT chain because the UTM had no reason to accept a packet sent directly to it.  The second line is a logging of a similar packet by NAT rule #11.

    To fix this, the remote endpoint must know the internal IP of your VPN server or it must be in the equivalent of "Respond only" in WebAdmin.  If that has been done, then it seems likely that the Host definition for the VPN server violates #3 in Rulz.

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    Yes the VPN Server was on the edge before.  Wouldn't violating #3 in Rulz break all my VPNs?  I do think I'm probably violating it but didn't think any of my VPNs would work if I had it wrong.  To be fair I didn't find the Rulz until after the first test run.  So to be clear then I need to take my grouped definition of VPN IPs and allow the predefined IPsec services to 'Interface: >' and then use a DNAT rule to forward the IPsec traffic from the IPsec IPs group to the host definition of the VPN Server, or does it even need the DNAT?

    I guess I still don't understand by the IPsec traffic in the first firewall log entry got blocked at all.  It was from one of the IPsec endpoints and using UDP 500 with is in the predefined IPsec services group?  Is that also because of a rulz #3 violation?

    TIA