RV160 SNMP over IPSEC VPN tunnel

[MIkeDavis1973]

I've enabled SNMP over VPN tunnel but it doesn't work.  Has anyone else come across this issue?

Regards,

Mike

[balaji.bandi]

Do you have access policy for the VPN subnet to allow ?

[MIkeDavis1973]

Looking at the firewall rules, the VPN doesn't appear in the pick lists - you can only create rules to/from LAN and WAN, not to/from VPN.

Regards,
Mike

[nagrajk1969]

Hi Mike 

First post info on how exactly you have configured your VPN tunnel and where is your snmp-trap-receiver or your snmp-network-management-server?

1. Is this how you have deployed?

(lan-subnet1)----[RV160-GW1]wan-----site-to-site-ipsec-tunnel------wan[RV160-GW2]----(lan-subnet2)---[snmp-trap-receiver]

2. If yes, then please post the exact vpn tunnel config applied on GW1 and GW2

- what i mean is what are the Local/Remote traffic-selectors/subnets configured on each of the vpn-peer-gws?

3. Iam asking above questions for a very valid reason becos i know why its not working for you  and it depends on HOW you have configured the VPN tunnel...

Note: You should obfuscate your wan-ipaddresses or mention something else...but please mention clearly what are your lan-subnets configured and what are mentioned in your vpn tunnel policies on each GW....no need to hide any lan-networks....ALL OF US USE THE SAME RFC-1919 STANDARD  private ip subnets in our organizations - 10.x.x.x/8, 172.16.x.x/12 and 192.168.0.0/16....and these are all NOT routable over internet directly...they need to be nated to valid public ipaddresses (that you have configured on your wan-interfaces)....the point is dont try to change too much of your network settings when you post the info here....it unnecessarily creates confusion in our understanding....

thanks

[MIkeDavis1973]

Traffic is flowing both ways over the tunnel with no issue.  Both ends are using address space in the 172.16 range with no overlaps.  Head end is a Watchguard M400 and as mentioned, tunnel is up with no routing issues.  I can ping the RV across the tunnel and web browse to it, it's just that SNMP doesn't work.

[nagrajk1969]

Yes. I never doubted that the tunnel is working correctly and also the traffic is getting routed correctly without any issues

But with reference to issue observed with SNMP traffic, what i wanted to know was:

- Assuming that you have configured the subnet say for example 172.16.6.0/24 on the lan-side of RV160

1. On the RV160, is the ipsec policy configured as below?

Local-Subnet: 172.16.6.0/24

Remote-Subnet: ANY

- You see as far as i have observed:

a) the issue with routing of SNMP-traffic (traps/etc) from RV160 over the ipsec tunnel to a snmp-receiver in the lan-network behind the watchguard-m400 ipsec peer WILL HAPPEN ONLY IF YOU HAVE CONFIGURED THE IPSEC TUNNEL ON RV160 WITH THE POLICY AS MENTIONED here above (when remote-subnet is configured as ANY)

b) when you configure the remote-subnet as ANY as you have configured on the RV160, the issue is seen not only for snmp traffic, but even for routing Syslog-logs over the ipsec tunnel (to a syslog-server behind the M400-peergw

c) To solve your issue in this case there is a workaround that you have to apply

2. In case you have configured the ipsec tunnel as below (using some example subnets as shown below), then you SHOULD NOT BE SEEING ANY SUCH ISSUES WITH SNMP (OR SYSLOGS) AS REPORTED BY YOU..

Note: Iam assuming that the network behind M400-peer is 172.16.9.0/24

On RV160:

Local-Subnet: 172.16.6.0/24

Remote-Subnet: 172.16.9.0/24

On M400:

Local-Subnet: 172.16.9.0/24

Remote-Subnet: 172.16.6.0/24

[MIkeDavis1973]

Hi there,

At the far RV160 end of the tunnel, the tunnel is configured as local 172.16.6.0/24 to remote ANY, and the same is true at the M400 end (obviously in reverse).

From your reply, I couldn't understand if you said this was correct or incorrect - your post says that both 1. and 3. should work.

Many thanks,

Mike

[nagrajk1969]

Hello Mike

1. yes, my earlier post was little confusing...so i have now updated it with the correct info/points...now it should be more clearer to you

2. And thank you for providing the info on the subnets and the ipsec policy you have configured on the RV160. 

a) Firstly what you have configured (with remote-subnet ANY in either of the peers ) is absolutely correct. Please dont change any configs on either the RV160 or the M400. This is standard configs applied and required for Hub-and-Spoke vpn topologies...so continue to use it as is

b) Now, The ONLY issue with this config (using remote-subnet as ANY) in ALL RV160/RV340/345/260 series of router is that the routing of the SNMP/syslogs/dhcp-relay traffic generated BY/FROM THE RV160 gateway itself to remote destinations over the IPSec-Tunnel is a problem. This is what you are seeing...and its a BUG which is specific to ipsec tunnels confgured with remote-subnet ANY....other tunnel configs dont have this issue

3. So the ONLY way at present to solve this issue of snmp-traffic routing over the ipsec tunnel is to apply the below work-around steps on RV160 ONLY

a) Some Assumptions by me:

- Lets assume that the remote snmp-receiver or snmp-server behind the M400 peergw is with the ipaddr 172.16.9.101

- Also iam assuming that the vlan1/lan-interface ipaddr of RV160 is 172.16.6.1

Step-1: Next iam assuming and considering that the ipaddress 172.16,6,253 IS NOT ASSIGNED AND MUST NOT BE ASSIGNED TO ANY HOST/DEVICE/SERVER/PC/PRINTER/ETC IN YOUR LAN-NETWORK OF RV160

NOTE: THIS IS A MANDATORY REQUIREMENT AND MUST REQUIREMENT FOR THIS WORKAROUND TO WORK CORRECTLY IS TO ENSURE THAT 172.16.6.253 (or any such ipaddr in the subnet 172.16.6.x) IS NOT ASSIGNED TO ANY HOST/DEVICE/ETC ON YOUR LAN-NETWORK OF RV160

- if this ipaddr is assigned/active in your lan-network, then this work-around will NOT work

Step-2: So now in "Routing/Static-Routing" page of RV160-GUI, add a "dummy route" to the snmp-server ipaddr 172.16.9.101, exactly as shown in attached screen-shot, and apply/save

- similarly the same principle will apply when you want to route/send all syslogs generated by RV160 to a syslog-server behind M400-peer, say with the ipaddr 172.16.9.102...and so on

So what would happen is that whenever the RV160 gateway generates a snmp-trap and it has to be sent to the snmp-server (configured as 172.16.9.101 for example):

- by default and at present the RV160 will be trying to send the snmp-traps traffic with the source-ipaddr of the wan-interface address, becos this is where the default-route is pointing to....

- so by adding the "dummy-route" as in step-2, now the snmp-traffic generated by RV160 specifically to 172.16.9.101 WILL NOW be tried to be "routed" on vlan1 interface WITH THE SOURCE IPADDRESS OF 172.16.6.1 the vlan1-ipaddr,

- AND since there is a IPSec Policy of "172.16.6.0/24<>ANY protect with IPsec" AND SINCE THE SNMP-TRAFFIC PACKET THAT IS FORMED BY RV160 WITH SRC-ADDR OF 172.16.6.1 IS MATCHING THIS IPSEC POLICY, IT WILL BE CORRECTLY AND SIMPLY ROUTED OVER THE IPSEC TUNNEL

try this out, and iam 100% sure that this workaround will work for you...till the bug is fixed by Cisco

regards

[nagrajk1969]

Hi

Sorry i forgot to add an additional followup to my previous/last post:

The reason and the requirement to add the "dummy-route" in this specific vpn tunnel scenario is:

Your deployment is as below, and the ipsec tunnel is UP and working, and we will assume that there are NO dummy/static-routes at present:

lan-172.16.6.0/24----vlan1(172.16.6.1)[RV160]wan(101.101.101.11)-----101.101.101.1[ISP-router]-----[M400]--172.16.9.101

1. Now consider the case of you trying to access the web-GUI of RV160 across the IPsec tunnel from 172.16.9.101. 

- You will use the url as say "https://172.16.6.1". And remember that the tcp-connection is initiated from source ipadd 172.16.9.101 and the destination is 172.16.6.1

- This packet from 172.16.9.101 to 172.16.6.1 correctly matches the ipsec policy on M400 and is sent across the ipsec tunnel to RV160

2. Now what happens here is that, as per routing standards, the response/reply is always sent back using the same interface on which the connection/packets have been received. This means that the response/reply packets to the http/tcp connection is sent with the source-ipaddr of 172.16.6.1 to 172.16.9.101... This is standard routing behavior and is correct

- And the same routing principle applies to any other traffic sent or rather "Initiated" from 172.16.9.x network to 172.16.6.1 (which is the internal lan/vlan1 interface of RV160) and all this traffic correctly gets routed thru the already established ipsec tunnel

- the traffic that is "initiated" from 172.16.9.x network to 172.16.6.1 could be Ping, or say you do a snmp-get/snmpwalk from 172.16.9.101 to 172.16.6.1. All this will work and you are already seeing this work as expected

BUT....

3. In the case there are some events that "trigger" snmp-traps to be sent/initiated BY THE SNMP-SERVICE RUNNING ON RV160 to 172.16.9.101 (which we will assume is the snmp-server/trap-receiver configured in the snmp-gui pages of RV160), then this is a "new" connection or "new" traffic that is "initiated" from RV160. So below is what would happen 

a) When RV160(or the snmp-service) builds the packet (it would be udp packet in this case) to be sent to the destination ipaddr 172.16.9.101, it needs to select a source-ipaddr for the udp packet to be sent.

b) So when there is a route lookup done on RV160 for the destination 172.16.9.101, there is a "Default-Route" existing and this points correctly to the isp-router ipaddr 101.101.101.1 as the default-gateway....and the interface thru which this default-gateway/route is reachable is thru the "wan" interface

c) So, again as per routing standards, the source-ipaddress of the IP-Packet (that has the udp payload of the snmp-traps) that is sent out to a remote destination will always be the ipaddress of the outgoing interface.

- In this case, since the route-lookup identifies the best-path/route via the wan interface (to the default-gw isp-router), the snmp-trap packets sent out by the snmp-service on RV160 will now have the source-ipaddr of 101.101.101.11 and the destination-ipaddr will be 172.16.9.101

d) Now since this ip/udp snmp traffic has the src-ipaddr of 101.101.101.11, it does NOT match the configured ipsec policy on RV160 (which is "172.16.6.0/24<>ANY : Protect-with-IPsec"), and therefore it is simply routed out via the wan interface as a "plain" packet and NOT via the ipsec tunnel.

4. So the behavior and routing that is happening in Point-3 above is "correct" and standard routing behavior. This is NOT a issue/bug as far as the "default standard routing behavior on RV160" is concerned.

5. BUT we/you/the-user wants and the requirement is that all snmp-traffic "generated/initiated" from RV160 MUST BE SENT ACROSS THE IPSEC TUNNEL TO 172.16.9.101.

a) So this means that to match the ipsec policy the snmp-traffic initiated from RV160 to destination 172.16.9.101 must have a src-ipaddress of 172.16.6.1, and only then it will be routed via the ipsec tunnel

b) Hence the present workaround of adding the "dummy-route" comes into picture here, now.

6. So below is what happens when the "dummy-route" to 172.16.9.101 via the "inactive/dummy" gateway ipaddr 172.16.6.253 on vlan1 interface is added:

a) When the snmp-traps are "generated/initiated" by the snmp-service on RV160 to destination 172.16.9.101, the same route lookup happens, and now there is a explicit static-route present and therefore the "default-route" does not get applied here

b) So as per the "dummy/static-route" present, the packets for destination 172.16.9.101 is to be sent/routed to 172.16.6.253 on vlan1 interface, and therefore as per routing standards, NOW the source-ipaddr of these packets will be 172.16.6.1

c) And since there is a IPsec Policy enabled and active on RV160, and now since the snmp-packets that are to be sent to 172.16.9.101 are with the src-ipaddr of 172.16.6.1, it matches the ipsec-policy "172.16.6.0/24<>ANY" and therefore this snmp-packet is simply forwarded/routed immediately via the ipsec tunnel

hope the above info helps in the understanding of the reasoning behind the requirement to add the workaround "dummy-static-route"

Note: again please note, the "gateway-ipaddr:172.16.6.253"  MUST NOT BE ACTIVE/REACHABLE ON THE VLAN1/LAN NETWORK