VPN traffic not inforced



  • While troubleshooting a misconfigured peer VPN I noticed that traffic which is defined by a VPN policy was being allowed by a normal policy.

    If a source IP is in a policy that says “tunnel”, and that traffic comes into the box outside of the tunnel, I would expect the firewall to drop that traffic and enforce the tunnel requirement.

    Instead the packet is moving on to another policy which allows it. Is there a way to change this behavior? Putting in a deny policy before the permit is not a scaleable option.

    We have a Voip server behind the firewalls that require udp port 5060 open from ANY tothis server. For clients that can NOT use SIP-DIGEST authentication, these client IP addresses are considered "trusted-hosts"
    in the Voip server. So to prevent spoofing of the src-ip header that could make it to the Voip Server, we require at a minimum AH IPSEC. So any packet that makes it to the Voip Server that contains a trusted src-ip,
    needs to be blocked unless authenticated via IPSEC through the firewall first.

    It sounds like with the current screenos design, we would need to put in a regular deny policy right after the tunnel permit policy.

    This would add complexity to our provisioning process and is not viewed as acceptable for a long-term solution.



  • I think you’ll find that most SIP proxy’s are not that sophisticated to have the same application do different things on different interfaces (this is what SBC’s are for) anyway, not the point here…

    According to Juniper (and debug), if a packet comes in unencrypted (ie, not protocol 50 or 51) it doesn’t even LOOK at the VPN policies, it jumps directly to the normal policies.

    Now I agree with that for ROUTE based VPN’s, however for POLICY based, I think the better thing to do is ENFORCE the policy based VPN’s by doing a lookup, a check, to make sure that the packet I’m receiving is coming from a tunnel. Doesn’t that make sense?

    The biggest concern in this scenario is spoofed src-ip. The netscreen can only block spoofed packets from sources it knows about, otherwise they’ll come right through. To really screw up a stateful SIP proxy using UDP based SIP you don’t have to have two-way communication. Just send the SIP proxy enough bogus crap and you’ll create denial of service. Send enough packets from a spoofed trusted source ip, and that’s even easier.

    Eric



  • I’m not 100% sure I understand your question. As I understand you have a single untrust IP that both “trusted” IP’s that need “ah/tunneling” and for all other hosts that use SIP-Digest auth? Am I right?

    It is a bit of a dilemma you need to trust these IP’s on the VOIP server. Isn’t it possible to put a deny policy at the top using port 5060 for the trust IP-addresses? Could you possibly instruct these users so use “AH/tunneling” at another untrust ip? My thought is this:

    Only let users that CAN use SIP-digest auth to logon via public IP-address 1.1.1.1 and access the SIP-server at private IP, lets say 192.168.1.1. In this configuration you have no trusted IP-addresses assiged to you SIP server on that interface. Then on a second interface on the SIP-server, lets say 192.168.2.1 have a list of trusted IP-addresses. This IP-address however is ONLY accessible through “AH/Tunneling”. Would this be possible to set up on your SIP server?

    Regards,
    oldO



  • Your assumption that VPNs on untrust needing a policy is correct.
    I’d use debug to see what’s going on.
    Clearly it’s not matching the policy or you’ve hit a bug. If you can you might try 5.1r4b to see if it behaves the same.

    http://ns5gt-support.netscreen.com/knowbase/root/public/ns10413.pdf?



  • I am running 5.1r3, we bind the tunnels to the untrust interface thinking that traffic would first arrive in the untrust and then be processed by policy.



  • Route based VPN with the tunnel in the trust? Traffic is allowed by default.
    Put tunnel in the untrust and you will need a policy.
    Otherwise need more info how the VPN is configured & version of ScreenOS.
    You might also try debug to see why it’s not getting caught by the policy you’d expect.



  • example policies;

    set address “prodtrust” “IPSEC_RANGE” x.x.x.y 255.255.255.224
    set address “produntrust” “Customer-net5” y.y.y.z 255.255.255.192 “C_04_T”

    VPN policies (they are before the normal one):

    set policy id 7990 from “prodtrust” to “produntrust” “IPSEC_RANGE” “Customer-net5” “ANY” tunnel vpn “vpn-16” id 4349 pair-policy 8005
    set policy id 8005 from “produntrust” to “prodtrust” “Customer-net5” “IPSEC_RANGE” “ANY” tunnel vpn “vpn-16” id 4349 pair-policy 7990

    Normal Policy:

    set policy id 103 from “produntrust” to “prodtrust” “Any” “Voip_server” “Port_5060” permit

    (Voip servers are inside .y/27 range)


 

26
Online

38.4k
Users

12.7k
Topics

44.5k
Posts