SRX Services Gateway
Highlighted
SRX Services Gateway

OpenVpn issue with rerouting interfaces

[ Edited ]
‎05-27-2019 10:07 AM

Hi guys,

New to this forum, so forgive me if I placed in wrong topic my issue.

 

The issue: I have an Openvpn server behind SRX with static nat. Everything works ok after the successful connection of openvpn client to the openvpn server but after a while (randomly 1~5 h) without any reason connection goes down.

Checked the openvpn server config and everything looks ok.

 

The topology:

I have an Openvpn Server behind my SRX 550 which is nated (statically).

A routing based policy with load balance for my reth interfaces (is not applied in openvpn interface)

I have configured my SRX to static nat the openvpn server to 1 public ip from our /28 block of Ips (reth2.150) and added proxy-arp for ISP requests since this ip is not the public interface of my SRX

Reth2.150 is my ISP's leased line interface. /28 block of ips.

Reth2.110 is my DMZ Wan gw for my OpenVpn internal ip.

Openvpn ip 10.0.110.11

 

Debug: After a tcpdump in both ways (client server) and on SRX I noticed the below when the connection of Openvpn went down. (same time for client/server) 

May 27 17:55:14 17:55:14.397463:CID-1:RT:<10.0.110.11/1201->x.x.x.x/1194;17> matched filter PF2:

May 27 17:55:14 17:55:14.397463:CID-1:RT:packet [112] ipid = 20559, @0x41d314ac

May 27 17:55:14 17:55:14.397463:CID-1:RT:---- flow_process_pkt: (thd 5): flow_ctxt type 15, common flag 0x0, mbuf 0x41d31280, rtbl_idx = 20

May 27 17:55:14 17:55:14.397463:CID-1:RT: flow process pak fast ifl 98 in_ifp reth2.110

May 27 17:55:14 17:55:14.397463:CID-1:RT: find flow: table 0x528ce8a8, hash 10400(0xffff), sa 10.0.110.11, da x.x.x.x, sp 1201, dp 1194, proto 17, tok 45

May 27 17:55:14 17:55:14.397463:CID-1:RT:  flow got session.

May 27 17:55:14 17:55:14.397463:CID-1:RT: flow fast tcp/udp session id 215478

May 27 17:55:14 17:55:14.397463:CID-1:RT:flow_ipv4_rt_lkup success x.x.x.x, iifl 0x0, oifl 0x10a

May 27 17:55:14 17:55:14.397463:CID-1:RT:  handle reroute for tunnel 0

May 27 17:55:14 17:55:14.397576:CID-1:RT:new output if pp0.3

May 27 17:55:14 17:55:14.397576:CID-1:RT:flow_ipv4_rt_lkup_reroute: session 0xf6000349b6 c2s if reth2.150 -> pp0.3

May 27 17:55:14 17:55:14.397576:CID-1:RT:  refreshing session

May 27 17:55:14 17:55:14.397576:CID-1:RT: vector bits 0x1020 vector 0x4b466ab8

May 27 17:55:14 17:55:14.397576:CID-1:RT:  vsd 1 is active

May 27 17:55:14 17:55:14.397576:CID-1:RT:mbuf 0x41d31280, exit nh 0xe20010

May 27 17:55:14 17:55:14.397576:CID-1:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

As you can see it changes the outbound interface. (reth2.150 is the incoming correct interface where openvpn accepts requests and should forward them back, where pp0.3 is an active interface (ppoe) that serves for Load-Balance which is member on rib-group in routing-options for PBR)

**The same happened with other openvpn client and SRX rerouted traffic from pp0.4 (is also member of load balance rib-group

 

I will post the configs in order to tell me if I am missing something.

 

Interface DMZ-WAN (openvpn server IP)

 show interfaces reth2.110
description DMZ-ZONE;
vlan-id 110;
family inet {
    address 10.0.110.1/24;
}

Interface for my Internet (one of them/ leased line)

# show interfaces reth2.150
description "*** FIBER FOR EMPL ***";
vlan-id 150;
family inet {
    address x.x.x.x/28 {
        primary;
    }
    address x.x.x.y/28;
}

Static Nat for Openvpn Server

show security nat static
from zone ISP_ALL_EMPL;
rule Openvpn-fiber match { destination-address x.x.x.x/32; } then { static-nat { prefix { 10.0.110.11/32; } } }

Proxy arp for this IP for arp requests from my ISP

show security nat proxy-arp
interface reth2.150 {
    address {
        x.x.x.x/32;
        y.y.y.y/32;
show security policies from-zone ISP_ALL_EMPL to-zone DMZ
policy VPN {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

I am not posting my routing-options config as I think that SRX don't want to check since we have static nat.

 

Please I need your help to fix this issue! I cannot find any wrong.

If you need more config files please let me know

 

Thank you in advance

 

Dimi,

CCNA-CCNP-JNCIA-MCSA

 

13 REPLIES 13
Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-27-2019 10:39 AM

HI Dimi,

 

The flow trace shows traffic flow "10.0.110.11/1201->x.x.x.x/1194;17" is entering on "reth2.110" and leaving out on "pp0.3".

Please check the output of "show route x.x.x.x detail" during working and non-working state to confirm if the route changes and if so why ?

 

SRX is not dropping the packet but re-routing it through pp0.3 interface. If you believe this should not happen then please check the route table during non-working state to find out the reason for change in interface.

 

Thanks,

Kinshuk

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-27-2019 11:14 AM

Hi Kinshuk,

Thanks for your reply.

It is wrong to rerouting it because the session was established in reth2.150 interface. So when the reply of the session goes out the pp0.3 interface, clients sees another public ip with another session id which is unknown for it and the packet is correctly ignored.

 

The output right now (it works) is the below

show route x.x.x.x detail

inet.0: 144 destinations, 150 routes (143 active, 0 holddown, 1 hidden)
x.x.x.x/32 (1 entry, 1 announced)
        *Static Preference: 1
                Next hop type: Receive
                Address: 0x12d4510
                Next-hop reference count: 13
                State: <Active Int ProxyArp>
                Age: 5w4d 9:28:32
                Validation State: unverified
                Task: RPD Unix Domain Server./var/run/rpd_serv.local
                Announcement bits (2): 0-KRT 2-Resolve tree 1
                AS path: I

Below shows all the other routing-instances that i have configured, but in many of them this route isn't configured as next-hop. I don't understand why it shows me the block /28 with these instances  

routing-smtng.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

x.x.x.x/28 (2 entries, 1 announced)
        *Direct Preference: 0
                Next hop type: Interface
                Address: 0x1514010
                Next-hop reference count: 16
                Next hop: via reth2.150, selected
                State: <Secondary Active Int>
                Age: 12w4d 9:03:52
                Validation State: unverified
                Task: IF
                Announcement bits (1): 1-KRT
                AS path: I
                Primary Routing Table inet.0
         Direct Preference: 0
                Next hop type: Interface
                Address: 0x1514600
                Next-hop reference count: 15
                Next hop: via reth2.150, selected
                State: <Secondary Int>
                Inactive reason: No difference
                Age: 12w4d 9:03:52
                Validation State: unverified
                Task: IF
                AS path: I
                Primary Routing Table inet.0

routing-table-all-empl.inet.0: 129 destinations, 134 routes (128 active, 0 holddown, 1 hidden)

x.x.x.x/28 (2 entries, 1 announced)
        *Direct Preference: 0
                Next hop type: Interface
                Address: 0x1514010
                Next-hop reference count: 16
                Next hop: via reth2.150, selected
                State: <Secondary Active Int>
                Age: 12w4d 9:03:52
                Validation State: unverified
                Task: IF
                Announcement bits (1): 1-KRT
                AS path: I
                Primary Routing Table inet.0
         Direct Preference: 0
                Next hop type: Interface
                Address: 0x1514600
                Next-hop reference count: 15
                Next hop: via reth2.150, selected
                State: <Secondary Int>
                Inactive reason: No difference
                Age: 12w4d 9:03:52
                Validation State: unverified
                Task: IF
                AS path: I
                Primary Routing Table inet.0

routing-table-email.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

x.x.x.x/28 (2 entries, 1 announced)
        *Direct Preference: 0
                Next hop type: Interface
                Address: 0x1514010
                Next-hop reference count: 16
                Next hop: via reth2.150, selected
                State: <Secondary Active Int>
                Age: 12w4d 9:03:52
                Validation State: unverified
                Task: IF
                Announcement bits (1): 1-KRT
                AS path: I
                Primary Routing Table inet.0
         Direct Preference: 0
                Next hop type: Interface
                Address: 0x1514600
                Next-hop reference count: 15
                Next hop: via reth2.150, selected
                State: <Secondary Int>
                Inactive reason: No difference
                Age: 12w4d 9:03:52
                Validation State: unverified
                Task: IF
                AS path: I
                Primary Routing Table inet.0

 

 

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-27-2019 03:25 PM

Hi Dimig,

 

I am not sure about the topology at this point. Could you please provide a rough topology diagram and the SRX config ?

 

The following config looks confusing  / incorrect:

from zone ISP_ALL_EMPL;
rule Openvpn-fiber match { destination-address x.x.x.x/32; } then { static-nat { prefix { 10.0.110.11/32; } } }

 

Taking the flow trace into consideration,  "10.0.110.11/1201->x.x.x.x/1194" would mean that Open VPN server is sennding packet  with Source IP it's private IP and destination IP of it's Public IP (NAT'd IP). This looks wrong!
The destination IP should have been the IP address of the OpenVPN client. 

 

 

Thanks,

Kinshuk

Any reason why the traffic is destined to OpenVPN server's own IP address ?

 

 

 

 

 

 

 

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-27-2019 06:34 PM

Dimi,

 

I believe we are confused because in the flow traces the x.x.x.x address was representing the public address of the OpenVPN client (remote user):

 

 

May 27 17:55:14 17:55:14.397463:CID-1:RT:<10.0.110.11/1201->x.x.x.x/1194;17> matched filter PF2:

 

 

However, in your static NAT configuration it represents the public IP address linked to the proxy-arp configuration, am I right? in summary you used the x.x.x.x address to represent two different public addresses and this is the root of the confusion.

 

 

show security nat proxy-arp
interface reth2.150 {
    address {
        x.x.x.x/32;

 

 

I understand that the topology (when the traffic works) is like this:

 

OpenVPN_Server------------(reth2.110)-SRX-(reth2.150)-------------INTERNET------------OpenVPN_Client

 

Please confirm under which routing-instance(s) are reth2.110, reth2.150 and pp0.3 interfaces configured.

 

You also mentioned you have PBR configured, so I assume you have a filter applied as input on interface reth2.110, please confirm if this is true and if possible share the configuration of the filter.

 

Please share a "show route [remote_user_address] detail" command.

 

 

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-27-2019 06:44 PM

Please also filter your flow trace log file in order to confirm if the following message is reported: re-route-failed

 

> show log [file_name] | match "re-route failed"

 

And please share a "show version" and "show chassis hardware" command. I would to run the following command but I need first to see the previously requested outputs: show usp flow counters all.

 

 

 

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-28-2019 01:44 AM

Hi guys,

 

Yes you are right and I am sorry for the confussion.

I represented 2 different addresses with the same letter.

So,

Topology is, as correctly mentioned 

 

 

May 27 17:55:14 17:55:14.397463:CID-1:RT:<10.0.110.11/1201->1.1.1.1/1194;17> matched filter PF2:

 

 

 

show security na static
from zone ISP_ALL_EMPL; rule Openvpn-fiber match { destination-address 2.2.2.198/32; } then { static-nat { prefix { 10.0.110.11/32; } } }

 

show security nat proxy-arp
interface reth2.150 {
    address {
     2.2.2.198/32;
     other_public_ip_of_the_same_block_for_other_service/32;

As for the PBR this interface is not configured anymore with the filter. i deleted before the issue and the issue persists

 

 

 show interfaces reth2.110
description DMZ-ZONE;
vlan-id 110;
family inet {
    address 10.0.110.1/24;
}

the filter that WAS applied is:

 

 

# show firewall filter redirect-traffic-fiber
term default-table {
    from {
        destination-address {
            10.0.0.0/8;
            192.168.0.0/16;
            172.16.0.0/22;
        }
    }
    then accept;
}
term to-fiber{
    then {
        routing-instance routing-table-fiber;
    }
}

and the instance is

 

# show routing-instances routing-table-fiber
instance-type forwarding;
routing-options {
    static {
        route 0.0.0.0/0 next-hop 2.2.2.193/32;--->the gw of my ISP from the /28 block
    }
}

So now for the question concerning under which routing-instance(s) are reth2.110, reth2.150 and pp0.3 we have:

 

reth2.110 is a DMZ int and is not applied in any routing-instance because is not a provider's interface

reth2.150 is applied with my ISP's gw 2.2.2.193

pp0.3 is also applied

 

# show routing-instances
routing-smtng-inf {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop pp0.4;
        }
    }
}
routing-table-Dept1-to-Internet {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 2.2.2.193;---->my ISP gw
        }
    }
}
routing-table-Dpt2-to-Specific public_srv {
    instance-type forwarding;
    routing-options {
        static {
            route a.a.a.a/32 next-hop pp0.3;
        }
    }
}
routing-table-all-empl {
    instance-type forwarding;
    routing-options {
        static {
            route ...... /32 next-hop pp0.3;
            route ......./32 next-hop pp0.3;
            route 0.0.0.0/0 next-hop [ pp0.1 reth2.2222 pp0.3 pp0.5 2.2.2.193 ];
            route ....../32 next-hop pp0.1;
            route ...../32 next-hop pp0.1;
            route ...../32 next-hop pp0.3;
            route 192.168.0.0/16 next-hop 10.0.111.254;----->DMZ-lan for internal openvpn communication (2nd interface)
        }
    }
}
routing-table-email {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop pp0.2;
        }
    }
}
routing-table-fiber{
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 2.2.2.193;
        }
    }
}
routing-table-guests {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop pp0.0;
        }
    }
}
routing-table-serv-vpns {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop b.b.b.b/32;
        }
    }
}
routing-table-servers-fiber {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop [ b.b.b.b 2.2.2.193 ];
        }
    }
}

right now traceoptions are configured to rewrite until maximux size is reached, so until now, i don't have any disconnections. i will post as soon as i notice any disconnection

 

Version: Model: srx550
JUNOS Software Release [12.3X48-D55.4] clustered 

 

 

 

 

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-28-2019 01:59 AM

also the show route detail

 

show route 1.1.1.1 detail

inet.0: 144 destinations, 150 routes (143 active, 0 holddown, 1 hidden)
0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 262142
                Address: 0x150e4d8
                Next-hop reference count: 3
                Next hop: a.a.a.a via reth2.2222
                Session Id: 0x4d
                Next hop: via pp0.0
                Session Id: 0x0
                Next hop: via pp0.1
                Session Id: 0x0
                Next hop: via pp0.2, selected
                Session Id: 0x0
                Next hop: via pp0.4
                Session Id: 0x0
                Next hop: via pp0.3
                Session Id: 0x0
                Next hop: b.b.b.b via reth2.2211
                Session Id: 0x79
                Next hop: via pp0.5
                Session Id: 0x0
                Next hop: 2.2.2.193 via reth2.150
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 76w6d 15:55:06
                Validation State: unverified
                Task: RT
                Announcement bits (2): 0-KRT 2-Resolve tree 1
                AS path: I

routing-smthng-.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 609
                Address: 0x151594c
                Next-hop reference count: 5
                Next hop: via pp0.4, selected
                Session Id: 0x0
                State: <Active Int Ext>
                Age: 14:05:19
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-all-empl.inet.0: 129 destinations, 134 routes (128 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 262144
                Address: 0x1654718
                Next-hop reference count: 2
                Next hop: b.b.b.b via reth2.2211
                Session Id: 0x4d
                Next hop: via pp0.1
                Session Id: 0x0
                Next hop: via pp0.3, selected
                Session Id: 0x0
                Next hop: via pp0.5
                Session Id: 0x0
                Next hop: 2.2.2.2.193 via reth2.150
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 76w6d 15:55:05
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-email.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 2188
                Address: 0x1515bf8
                Next-hop reference count: 10
                Next hop: via pp0.2, selected
                Session Id: 0x0
                State: <Active Int Ext>
                Age: 9w5d 22:43:47
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-servers-fiber.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 262143
                Address: 0x157c010
                Next-hop reference count: 2
                Next hop: b.b.b.b via reth2.2211, selected
                Session Id: 0x4d
                Next hop: 2.2.2.193 via reth2.150
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 32w6d 1:56:58
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-serv-vpns.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 1971
                Address: 0x1515310
                Next-hop reference count: 9
                Next hop: a.a.a.a via reth2.2222, selected
                Session Id: 0x4d
                State: <Active Int Ext>
                Age: 32w6d 1:56:58
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-guests.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 958
                Address: 0x1515ea4
                Next-hop reference count: 5
                Next hop: via pp0.0, selected
                Session Id: 0x0
                State: <Active Int Ext>
                Age: 3w4d 3:58:35
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-Dpt1-to-Internet.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 2132
                Address: 0x1514944
                Next-hop reference count: 15
                Next hop: 2.2.2.193 via reth2.150, selected
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 12w4d 23:46:10
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I

routing-table-fiber.inet.0: 102 destinations, 107 routes (101 active, 0 holddown, 1 hidden)

0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 2132
                Address: 0x1515e58
                Next-hop reference count: 3
                Next hop: 2.2.2.193 via reth2.150, selected
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 1w5d 19:26:41
                Validation State: unverified
                Task: RT
                Announcement bits (1): 1-KRT
                AS path: I
Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

[ Edited ]
‎05-28-2019 06:22 PM

Dimi,


Based on the configuration, reth2.110 and reth2.150 are not configured under any custom routing-instances so they will be configured by default under the Master/Default routing-instance (inet.0).


If a packet destined to 1.1.1.1 comes in to reth2.110, the inet.0 routing-table will be checked and based on the provided information the route from inet.0 is the following:

 

show route 1.1.1.1 detail

inet.0: 144 destinations, 150 routes (143 active, 0 holddown, 1 hidden)
0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 262142
                Address: 0x150e4d8
                Next-hop reference count: 3
                Next hop: a.a.a.a via reth2.2222
                Session Id: 0x4d
                Next hop: via pp0.0
                Session Id: 0x0
                Next hop: via pp0.1
                Session Id: 0x0
                Next hop: via pp0.2, selected
                Session Id: 0x0
                Next hop: via pp0.4
                Session Id: 0x0
                Next hop: via pp0.3
                Session Id: 0x0
                Next hop: b.b.b.b via reth2.2211
                Session Id: 0x79
                Next hop: via pp0.5
                Session Id: 0x0
                Next hop: 2.2.2.193 via reth2.150
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 76w6d 15:55:06
                Validation State: unverified
                Task: RT
                Announcement bits (2): 0-KRT 2-Resolve tree 1
                AS path: I

 

I can see diferent next-hops showing up and I would like to confirm if this is expected. Can you share the configuration of that default route under [edit routing-options static].


When we configure multiple next-hops for a route, without specifying any preference/prioritization between them, they will all have the same chances to be elected as the next-hop for that route. Actually Junos does the next-hop selection randomly, so at any given time reth2.150 can be the next-hop and out of the sudden we could see pp0.4 interface showing as the next-hop, because it is equally preferable as reth2.150. I believe this is the root cause of your issue.


I could think of three possible scenarios here:


1. You have the incorrect configuration and you only need reth2.150 as the next-hop for your default-route.


2. You might want to use "qualified next-hop" feature in order to have multiple next-hops, different than reth2.150, but have them as backup in case reth2.150 fails:

 

     https://www.juniper.net/documentation/en_US/junos/topics/concept/routing-protocol-static-security-ro...

 

3. You are trying to configure load-balance among all those next-hops. In that case you will need to load balance per flow (even though the command says per-packet it works per flow):

 

     https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ecmp-flow-based.html

 

I hope this helps

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

[ Edited ]
‎05-29-2019 12:23 AM

Hi 

 

Thanks for your detailed answer.

The purpose of those multiple routes is load-balance for 0.0.0.0/0.

 

 

# show routing-options
interface-routes {
    rib-group inet fbf-group-ISP-traffic;
}
static {
    route b.b.b.b/32 next-hop pp0.1;
    route 0.0.0.0/0 next-hop [ pp0.2 pp0.3 pp0.1 pp0.0 reth2.2222 pp0.4 reth2.2211 pp0.5 2.2.2.193];
    route f.f.f.f/24 next-hop pp0.3;
    route a.a.a.a next-hop pp0.3;
    route z.z.z.z/32 next-hop reth2.2222;
    route v.v.v.v/32 next-hop pp0.3;
    route y.y.y.y/24 next-hop 2.2.2.193
    route ...../ next-hop .....
other routes have been ommitted } rib-groups { fbf-group-ISP-traffic { import-rib [ routing-table-email.inet.0 routing-smtng.inet.0 routing-table-guests.inet.0 routing-table-all-empl.inet.0 routing-table-servers-fiber.inet.0 routing-table-Dpt1-to-Internet.inet.0 routing-table-fiber.inet.0 ......inet.0 ......]; } } forwarding-table { export load_balance; }

So the correct scenario is 3rd. But i have already configured it like that.

policy-statement load_balance {
    then {
        load-balance per-packet;
    }
}

This is what you propose right?

 

Thank you so much

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎05-29-2019 12:41 AM

If I create a firewall filter to use as next-hop, only the 2.2.2.193 ip and add it as input in reth2.110 will save the situation?

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

[ Edited ]
‎05-29-2019 05:25 PM

Dimi,

 

In theory it should work but I think that was the way you had it configured before, wasnt it? If you do it like that then the default route present in the forwarding routing-instance will only have one next-hop (2.2.2.193) and I dont think the SRX will be rerouting the flow via different interfaces because ECMP wont be configured on that routing-instance. Try it and gather the following command to confirm that ECMP configuration is not affecting the forwarding routing-instance:

 

> show route forwarding-table destination 1.1.1.1

 

I would have expected that the SRX will never change the outgoing interface for a specific flow but based on the following PR it seems like it will do it:

 

"because of frequent reroute of the flow session between interfaces"

 

https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1410233

 

Please mark this comment as the Solution if applicable
Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎09-17-2019 12:59 PM

Sorry guys for the delayed response, but everything worked like a charm after a reboot!!!!!!!

Thank you all for your patience and advices!

Highlighted
SRX Services Gateway

Re: OpenVpn issue with rerouting interfaces

‎09-29-2019 08:32 AM

dimi,

 

Im glad everything worked fine, please mark the post as Resolved so future folks can find the anwer quickier.

 

Feedback