SRX

Okay guys, I've done a fair amount with Cisco devices, but I'm a Juniper noob and need some assistance.

I've set up an OpenVPN server on our internal LAN and we've got a public IP that forwards to the OpenVPN server. Here are the symptoms of my problem:

What works:

- The VPN clients can establish the connection with the server without any issue.

- VPN Clients can ping everything on our internal LAN no problem.

- Machines on internal LAN can access VPN clients just fine

- Once a machine on the internal LAN accesses say a file share on a VPN client, everything works great for about 60 seconds and then closes

What doesn't work:

- VPN clients cannot access DNS, File shares, SSH, or seemingly any other service besides ICMP

I've placed the VPN subnet into the trust zone

I've created a custom application on UDP port 1194 for OpenVPN

I've created a static route on the Juniper from the VPN subnet (10.8.0.0/24) to next-hop to the VPN server (192.168.1.44)

I've set permit FW rules (from trust to trust, anything) - (from trust to untrust, OpenVPN app) - (from untrust to trust, OpenVPN app)

Not sure what I'm missing, but here's some debug output that seems to show the reason is that traffic isn't getting routed back to the client because a session wasn't created on the way in???

Jul 31 12:13:58 12:13:58.442592:CID-0:RT:<10.8.0.2/32494->192.168.0.113/22;6> matched filter MatchTraffic:
Jul 31 12:13:58 12:13:58.442592:CID-0:RT:packet [40] ipid = 33869, @40e7e080
Jul 31 12:13:58 12:13:58.442592:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 8, common flag 0x0, mbuf 0x40e7de80, rtbl_idx = 0
Jul 31 12:13:58 12:13:58.442592:CID-0:RT:fto 0x41dc2070 
Jul 31 12:13:58 12:13:58.442592:CID-0:RT:nh word 0x350010 
Jul 31 12:13:58 12:13:58.442592:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

Jul 31 12:14:01 12:14:01.472914:CID-0:RT:<192.168.0.113/22->10.8.0.2/32494;6> matched filter MatchTraffic:
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:packet [52] ipid = 0, @4039951a
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x40399300, rtbl_idx = 0
Jul 31 12:14:01 12:14:01.472914:CID-0:RT: flow process pak fast ifl 67 in_ifp fe-0/0/0.0
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  fe-0/0/0.0:192.168.0.113/22->10.8.0.2/32494, tcp, flag 12 syn ack
Jul 31 12:14:01 12:14:01.472914:CID-0:RT: find flow: table 0x44eb0620, hash 33320(0xffff), sa 192.168.0.113, da 10.8.0.2, sp 22, dp 32494, proto 6, tok 6 
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  no session found, start first path. in_tunnel - 0, from_cp_flag - 0
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:flow_send_icmp_tcp_rst: Sending tcp-rst
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0  
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  encap vector
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  no more encapping needed
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  **** pak processing end.
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  packet dropped, first pak not sync
Jul 31 12:14:01 12:14:01.472914:CID-0:RT:  flow find session returns error.
Jul 31 12:14:01 12:14:01.472914:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

Hello Nichos,

From What I can see SRx is not seeing syn but the syn-ack.

Which means the syn is going through different route and not through the SRX.

Assymetric routing situation.

Can you put up a rough network connectivity diag and also config snippet of srx to help you out.

Regards,

c_r

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too

Below is the relevant information from the Juniper config. I've scrubbed private data and things I didn't think applied. Also is a quick and dirty network diag of the configuration. I have found that if I use the no-syn-check option, everything works, but I'd like to get it working without that vulnerability if possible.

interfaces {
    fe-0/0/0 {
        description LAN;
        speed 100m;
        link-mode full-duplex;
        unit 0 {
            description LAN;
            family inet {
                address 192.168.1.1/23 {
                    primary;
                    preferred;
                }
                address 172.16.1.1/16;
            }
        }
    }
    fe-0/0/1 {
        description Freewire_WAN;
        speed 100m;
        link-mode full-duplex;
        unit 0 {
            description Freewire_WAN;
            family inet {
                address <<OurPublicIP>>;
            }
        }
    }
}

routing-options {
    static {
        route 0.0.0.0/0 next-hop <<ISP Gateway>>;
        route 10.8.0.0/24 next-hop 192.168.1.44;
    }
}

security {
    nat {
        source {
            static {
                rule VPN {
                    match {
                        destination-address <<PublicIPofVPNServer>>;
                    }
                    then {
                        static-nat {
                            prefix {
                                192.168.1.44/32;
                            }
                        }
                    }
                }
            }
        }
    }
    zones {
        security-zone trust {
            tcp-rst;
            address-book {
                address OpenVPNServer 192.168.1.44/32;
                address OpenVPNClients 10.8.0.0/24;
                
                address-set OpenVPNSet {
                    address OpenVPNServer;
                    address OpenVPNClients;
                }
            host-inbound-traffic {
                system-services {
                    ping;
                }
            }
            interfaces {
                fe-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            http;
                            https;
                            ssh;
                            telnet;
                            dhcp;
                            ping;
                            dns;
                            ntp;
                            sip;
                            snmp;
                        }
                    }
                }
            }     
        }
        security-zone Freewire_untrust {
            address-book {
                address Freewire_OpenVPNServer <<PublicIPofVPNServer>>;
                
                address-set Freewire_WAN_IPs {
                    address Freewire_OpenVPNServer;
                }
            }
            screen untrust-screen;
            interfaces {
                fe-0/0/1.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                    }
                }
            }
        }
    }
    policies {
        from-zone trust to-zone trust {
            policy default-permit {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone Freewire_untrust {
            policy OpenVPN_Allow_Out {
                match {
                    source-address any;
                    destination-address any;
                    application OpenVPN;
                }
                then {
                    permit;
                }
            }
        }
        from-zone Freewire_untrust to-zone trust {
            policy OpenVPN_Allow_In {
                match {
                    source-address any;
                    destination-address any;
                    application OpenVPN;
                }
                then {
                    permit;
                }
            }
        }
    }
}
applications {
    application OpenVPN {
        protocol udp;
        destination-port 1194;
    }
}
            

Hello Nichos,

I see that actual traffic is :

10.8.0.2/32494->192.168.0.1
I do not see the Ip 192.18.0.113 anywhere in the diagram.
Also I see that the vpn client is doing an ssh to 192.168.0.113.
Now can you check what is the default gateway for 192.168.0.113?
IIS it the firewall?

Also i f i understand correctly the packet flow would be something like this : Client -- VPN serever. VPN server wuld then decrypt the packet sned the original packet to the desination and back.Please correct me if I am wrong.

Rgards,
c_r

192.168.0.113 is connect to the switch just like all the others in the diagram. Gateway on that machine is the juniper (192.168.1.1)

Thank you,

P.S. Not sure if I mentioned, but might be pertinent, the VPN connection also works correctly if I enable NATing on the VPN server interface, but I need this to work as a routed connection due to our softphone software not being able to traverse NATed connections.

Ok,

Can you try this:

a source NAT on the SRX for traffic from 10.8.0.2 to 192.168 with source NAT as the SRx interface?

Regards,

c_r

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too

Is this configuration complete? I mean you are applying static NAT only right? If yes what is the "from" clause? For static NAT we need to say from the packet comes. Can you please get that details as well.

ecurity {
    nat {
        source {
            static {
                rule VPN {
                    match {
                        destination-address <<PublicIPofVPNServer>>;
                    }

Hello Nichos,

If I understand the flow correctly.

The packet fromclient will reach firewall from your internal OPEN VPN server.

I would suggest to write a source nat from vpn client (from zone) to the server 192.168.0.13 (to zone), to take the interface of teh SRx, i.e then source nat interface.

Regards,
c_r

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too