Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 6479 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

Site to Site IPSEC VPN with Juniper - Packet Filter

pmcdaniel
We have setup a IPSEC Site to Site VPN between our ASG220 and a Juniper firewall on the remote site.  The only issue is that the automatic packet filter rules don't seem to be working properly.  Currently, the only way we can get all necessary services to work from the Juniper side is to have a packet filter rule enabled to allow Any > Any > Internal Network.  As soon as that rule  is disabled we lose the ability to do anything from the Juniper site other than was is already allowed on the Astaro, such as Ping and HTTPs access to the Astaro.  Services from the Astaro side to the Juniper side, such as RDP still work fine with that rule disabled.

We have also added the following manual Packet Filter rules with no success:
Remote Site LAN > Any > Internal (LAN) Network
Remote Site WAN > Any > Internal (LAN) Network
Remote Site LAN > Any > External (WAN) Address
Remote Site WAN > Any > External (WAN) Address

Obviously, we don't want to leave the current rule (Any > Any > LAN) enabled, so any help would be appreciated.


This thread was automatically locked due to age.
  • 0
    Please remember to always state the exact version of Astaro - 8.103 (8.202)?

    What do you see in the Packet Filter (Firewall) log when the Any-Any-Any rule is not in place?  Have you selected 'Auto packet filter (firewall)' rules in the 'IPsec Connection'?

    Cheers - Bob
  • 0 in reply to BAlfson
    Sorry, it is 8.103.

    Auto packet filter is on, not using strict routing.

    Nothing is jumping out at me from the packet filter log other than some DNS requests:

    2011:11:08-20:01:05 ASG220 ulogd[5341]: id="2014" severity="info" sys="SecureNet" sub="packetfilter" name="DNS request" action="DNS request" fwrule="60011" initf="eth1" srcmac="c8:4c:75:77:7c[:D]9" dstmac="0:1a:8c:16:ac:91" srcip="192.168.58.110" dstip="192.168.1.18" proto="17" length="77" tos="0x00" prec="0x00" ttl="127" srcport="61688" dstport="53" 
    2011:11:08-20:01:05 ASG220 ulogd[5341]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth1" outitf="eth0" srcmac="c8:4c:75:77:7c[:D]9" dstmac="0:1a:8c:16:ac:91" srcip="192.168.58.110" dstip="192.168.1.18" proto="17" length="77" tos="0x00" prec="0x00" ttl="126" srcport="61688" dstport="53" 

    One thing I just noticed is that I assigned the network definition of the Juniper LAN to the Internal interface on the Astaro.  Could that have caused this?  I changed it to External but I can't change the packet filter rule until later this evening to see.
  • 0
    One thing I just noticed is that I assigned the network definition of the Juniper LAN to the Internal interface on the Astaro. Could that have caused this?
    Do not bind network/host definition objects to interfaces.  In most cases this is not necessary and will break communications.  Leave (or change back) the bindings back to the default >.  The only network definition objects which should be bound to an interface are the default Internet objects.
  • 0 in reply to Scott_Klassen
    That's interesting...I've always bound network definitions to an interface, but this is the first site-to-site I've set up with an Astaro, so this is the first time it has caused an issue.

    I'll set it to Any and give it a try later this evening when the office is empty again.
  • 0
    Scott's right.  I just did a short engagement to clean up a configuration for a customer that had, among other mistakes, a half-dozen definitions bound to a specific interface.

    The only place where this made any difference was one used as the destination in the traffic selector of a NAT rule - without the binding, the DNAT would not have worked. However, the correct solution is to put an Additional Address on the interface, and then use the (Address) object created by WebAdmin in the NAT rule.  I left their ASG with only the default "Internet" definition bound to an interface.

    As in the DNAT I just described, it appears that your binding of the Juniper LAN definition to an interface caused the packet filter rule to be applied to the INPUT chain (packets sent "to" the Astaro) instead of to the FORWARD chain (packets sent through the Astaro).  That's the reason you got a 60002 - a default drop out of the FORWARD chain.

    da_merlin recently commented that one reason to bind some definitions to an interface is to prevent spoofing, but that having spoof-protection turned on solved that in general.  He also said:
    IPSec traffic going through an IPSec Tunnel will not match such Host definitions,
    even if they arrive or will be send via that interface. But thats not an technical issue,
    that was a design decision to be v7 compatible.


    Cheers - Bob
  • 0 in reply to BAlfson
    Removing the interface binding fixed it.

    We now have two-way traffic using only the automatic packet filter rules.

    Thanks alot!