Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 6484 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.
Parents
  • 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
Reply
  • 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
Children