cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8952
Views
40
Helpful
28
Replies

Firewall blocking traffic to static route on RV340

Fred Johnson
Level 1
Level 1

Hello friends,

We purchased an RV340 to replace an aging router. The switch was mostly painless except for one issue. Traffic to/from our openvpn service is being interrupted. Our setup is similar to the bottom of this page, we are using a static route to route traffic to 10.8.0.0/24 to a machine on VLAN1 (192.168.0.5). Machines on VLAN1 can ping vpn clients (10.8.0.5) but not the other way around. UDP seems to work both ways fine, but TCP does not. When trying to SSH from inside, I get this message in the logs on the router:

kernel: [87023.255407] FIREWALL:PACKET DROP IN=eth3.1 OUT=eth3.1 MAC=ec:fd:1d:44:8a:21 9c:f6:54:af:e8:a0 08:00:45:01:01:5d src=192.168.0.136 DST=10.8.0.7 LEN=93 TOS=0x00 PREC=0x00 TTL=63 ID=5207 DF PROTO=TCP SPT=34696 DPT=22 WINDOW=229 RES=0x00 ACK PSH URGP=0 MARK=0xff00

I've tried adding firewall access rules for 10.8.0.0 with no change. Even disabling the firewall did not seem to help. Does anything stand out to anyone or is there any advice on what to try next?

Thanks for reading!

 

UPDATE: It's been a little over a year and after spending some time checking today, the seems to be fixed. My setup hasn't changed much but I have upgraded the firmware on the router twice. Presumably this has fixed what ever the issue was.

28 Replies 28

We have an OpenVPN Connection to another company via internal server (IP 192.168.77.108) connected to the router. We have defined a static route to the other private network (10.80.20.0/24) which is connected over internet.

 

we can ping the other network, but no application can be run. i can see many dropped packets although we have switched off the firewall.

With our old router the system worked fine.

 

 

Unluckily this problem exists already for 3 years...never solved... static routes "inside" means to VLAN as lan is not an option like in the old rv325 does not work... Obviously a serious bug...

The RV325 did not have this problem... 

If one has an idea... pls let me know...

I had this same issue in RV345. I used to have a rv320 and it works fine. If someone have a workaround for this, please let us know.

ruibenavente
Level 1
Level 1

Hi all,

 

Does anyone have a solution to this ridiculous problem?

I would be grateful if someone from Cisco looks into this matter and presents a solution...

This problem also happens on the RV-160.

 

Thanks

Rui

Hi,

According Cisco Support (several hours analysis from myself made wireshark and also online logs with wireshark and the routers log capability from Support itself on my machines) who was really motivated to help me with this Issue on 2x RV345 on different locations the outcome was:

 

The firewall stateful inspection cannot be completely switched off which causes this issue. (unexpected)

 

The RV325 (and other routers from different brands) does not have this issue, at least with the installed old firmware.

Cisco's support was politely answering the question, if I should update the working RV325 with the newest firmware, . better do not update , as it might be the same issue with the new firmware which is seen on the RV345...

 

KR

Michael

 

nagrajk1969
Spotlight
Spotlight

Hi

 would it be asking for much if you could kindly please post the schematic/block-diagram (say as a ppt diagram file) of your present network-deployment (alongwith the RV34X/RV160/RV260)?

- It would make it more easier to refer to the network-deployment schematic and understand 

a) what is your requirement?

b) what configurations have you applied and on which component in the network?

c) and what are the issues or present observations exactly?

 

I saw all the posts from the begining (since 2017-18 i think) and not one of you have thought it fit to post a network-schematic clearly showing the general network deployment that is being used and what is the exact routing issue observed ....where is the source of traffic and where is the destination...????

 

- has anybody bothered to do a trace of the packet-flow at different points of the network using wireshark and/or tcpdump?...where does the packet get dropped ...and what is the icmp-error-messages and/or any other error messages generated by which network component?

 

- Has anybody bothered to check whether there is any "Ip-redirect messages" being generated by the RV-routers or any other gateways in your networks that is resulting in the issues that you are observing???? Have any of you tried to understand calmly and logically why of what is being observed????

 

I think you will agree with me that the first thing to post by any/all of you is what is the network-deployment schematic?...and what are connected where in the network diagram and what are the issue you are observing....will go a long way to solve the issues by the highly skilled and experienced community members and also by the Cisco-team too

 

What is needed is the complete logical network information (with the exact ipaddress/subnet info)....please kindly provide it if possible

 

Note: Iam very sure you are all aware....there is no point in hiding ipaddressing that you have configured in your networks if they fall in the RFC-1918 private-address-range (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16)....we all use in our internal networks and they are are NOT directly accessible or routable over internet....so please do not hide the subnet/ipaddress info of your network...in the schematic

 

best wishes and regards

 

PS: Iam also just an ordinary customer who has bought RV-routers..so iam in the same boat as you all...and i dont have any particular agenda with anybody other than with myself

 

 

nagrajk1969
Spotlight
Spotlight

Hi

 

Are your network deployments somewhat as in attached ppt file? (These scenarios are configured in my network with RV345/260/160 and it has been working till now atleast..)

 

maybe the attached schematics will help us all to understand about the issue observed, and thus help in arriving at possible solutions if any

 

So could you kindly post the info refering to the network-deployment attached or as per your deployment?

 

 

thanks

 

ruibenavente
Level 1
Level 1

Hi again,

 

@michael.pammer 

Thank you Michael! Ok , the explanation from Cisco about the stateful firewal makes sense giving my  LOGs.

I'm waiting for a call from Cisco support in my country and I will update it in here.

 

@nagrajk1969 

My network is very similar as your attached ppt ( in place of internal router, I have a L3 switch).

 

Sure, I will post a diagram ASAP, of the affected network segment and I will explain in detail what is the problem.

 

Thank you all!

 

KR

Rui

ruibenavente
Level 1
Level 1

Hi all,

 

Attached you can find my network diagram and the problem details:

 

Thank you!

 

KR

Rui

nagrajk1969
Spotlight
Spotlight

Hi Rui,

 

Well, Irrespective of whether the firewall is disabled or enabled (which should be enabled)on the RV160(or RV34X/RV260), as per my understanding of the the network deployment of yours, the immediate solutions at this time would be:

 


Option-1:

 

Step-1: Keep the existing config for the vlan1-subnet 192.168.0.0/24 network on the RV160, including the lan-hosts getting their ipaddress assigned thru the vlan1 dhcp-server on RV160

 

Step-2: On the RV160, create another vlan-11 and configure a ipaddress 192.168.11.254/24. Keep all the lan-ports as tagged for vlan-11. For now, just disable the dhcp-server on this vlan11 interface
- ensure that the inter-vlan routing is enabled for both vlan1 and vlan11 on this RV160

 

Step-3: Connect the L3-SWITCH to say lan1-port of RV160. And both the switch-port and Lan1-port will be set as tagged/trunk-port (multi-vlan)

 

Step-4: On the L3-switch configure a vlan-11 interface and assign it the ipaddress 192.168.11.1/24. Add a default-route to 192.168.11.254 as below on this L3-switch (iam assuming that its a cisco-switch for example)

- switch# ip route 0.0.0.0 0.0.0.0 192.168.11.254 dev vlan11

- And keep the existing configs for the subnets 192.168.10.x/24 and 192.168.12.x/24 as is on this switch. Dont change anything.

 

Step-5: On the RV160,

 

- add the static route for destination network 192.168.10.0/24 via 192.168.11.1 dev vlan11

- and add the static route for destination and 192.168.12.0/24 to 192.168.11.1 dev vlan11

----------------------------------------------------------------------------------------

 

Option-2: I had something definitely in mind, but then again, It depends on whether you have the support for running dhcp-server on the L3-SWITCH..

 

Option-3: its quite cumbersome and does not really make sense to deploy. So i will post it later just as a reference solution

---------------------------------------------------------------------------------

 

In summary, with your existing config/deployment as is, there is definitely an issue/bug on the RV16X/RV34X/RV260 routers for this specific scenario, AND its NOT due to firewall...definitely.

- Its a Bug that needs to be fixed by Cisco...(and again, its not due to firewall)

 

- becos if my observations are right, the issue is NOT with Ping traffic between 192.168.0.x and 192.168.10.x/192.168.12.x networks ...BUT its an issue with TCP/UDP traffic for sure.

 

- Applying the Option-1 method will ensure that the inter-vlan-routing on Rv160 happens properly on different network interfaces, and this time the TCP/UDP connections should  work correctly

 

hope it works for you

 

thanks

 

 

Hi nagrajk,

 

Thanks a lot for your very detailed help; it will help for sure people with the same problem.

However, I will pass the responsibility on to the manufacturer, as they have to solve it and not us, with "workarounds"

willingness to help.

 

Thank you again!

 

Best regards

Rui

 

.

nagrajk1969
Spotlight
Spotlight

Hi

 

>>>>However, I will pass the responsibility on to the manufacturer, as they have to solve it and not us, with "workarounds"

>>>willingness to help.

 

1. You are absolutely correct. I most definitely agree with your statement and thoughts. This has to be fixed by Cisco.

 

2. Could you confirm that the option-1 "workaround" steps/config-method worked in your network deployment?

- this iam asking purely in academic interest. Gives a confirmation/feedback for any further R&D/Analysis/Debugging that never stops for a network-engineer and in my opinion should never stop till we retire

- so kindly please provide your feedback on the points/info discussed in the previous post, it would be very helpful

 

thank you so much again. It was truly nice to know you and discuss with you

 

best regards

 

Hi @nagrajk1969,

 

Due to the fact that the router in question is in production on a customer, I will not try your "workaround" as it would create great disruption, but I believe it would work.

I have another equipment from other brand and will install it to solve, for now, this problem on my customer (so much faster than waiting for Cisco to solve it!).

 

I am considering returning this equipment as it does not do what it is supposed to do and has already caused me a lot of wasted time.

 

Thanks a lot again for your support; nice to talk with you!

 

If you need any help, please send me a private message.

 

Kind regards

Rui

nagrajk1969
Spotlight
Spotlight

Thank you so much

 

best wishes & regards to you