3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network (349 Views)
Reply
Occasional Contributor
stavoprojekta_t
Posts: 5
Registered: ‎10-24-2013
Message 1 of 7 (349 Views)

3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

I have problems using this router.


I have setup IPSEC VPN from main Office (LAN_A - 192.168.0.0/22) with another branch office (LAN_B - 192.168.12.0/22). 

3Com at LAN_A has IP 192.168.1.6/22
3Com at LAN_B has IP 192.168.13.2/22 (router A), I have another router in this lan 192.168.13.1/24 (router B), which connects another lan 192.168.14.1/24 .

 

We have one PC_A with IP 192.168.13.15/24, gateway 192.168.13.2 (3com router to internet and to ipsec).

When I try to ping from 192.168.13.15 to 192.168.14.15 PC_B (computer behind router B) It cannot reach this computer.

 

I think, that problem is when PC_A is sending packet to default gateway 192.168.13.2, then 3com drops this packet instead of resending it to 192.168.13.1 (router B).

I thing, there is BUG in firmware of 3CREVF100-73. Have newest firmware 1.0.13

 

If You have same problem, please report it. My product is out of warranty, so no supported is available.

Trusted Contributor
Vince_Whirlwind
Posts: 401
Registered: ‎02-25-2013
Message 2 of 7 (334 Views)

Re: 3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

It looks more like there is a bug in your design.

 

You need to pay attention to your subnet masks. If you have a router with a x.x.13.0/22 IP address, and then you put a subnet elsewhere on your network that conflicts with this, then your router will never be able to find it.

The other fairly stinky aspect of this network design is that you have router-router links mixed up with host subnets. Routers should not span subnets out multiple ports, and host subnets should not have multiple routers on them.

 

Your description is also very confused - you give details of a "LAN_A", but then your problem doesn't refer to this LAN at all.

You then call your LAN_B router, Router_A, which is pretty mixed-up, then you have a PC on LAN_B which you call PC_A. You then a 3rd LAN which you don't call LAN_C, but you have a router and a PC on this unnamed LAN you call ROUTER_B and PC_B, even though they are obviously not on LAN_B.

Occasional Contributor
stavoprojekta_t
Posts: 5
Registered: ‎10-24-2013
Message 3 of 7 (319 Views)

Re: 3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

[ Edited ]

Ok, so to be clear, I am sending Network topology draw.

 When I change Gateway (GW) on .13.15 do 13.1, then ping works without problems.

 

 

 

IPSEC problém 3Com router.jpg

 

Trusted Contributor
Vince_Whirlwind
Posts: 401
Registered: ‎02-25-2013
Message 4 of 7 (312 Views)

Re: 3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

Good diagram!

 

What does a traceroute show, from 13.15 to 14.15?

 

What does a "show ip rout" show, for each RouterA & RouterB?

 

What does a "route print" show, on PC_A, immediately after you've tried the ping?

 

Connect another device on the 13.0/24 network on the same hub as PC_A - something like a switch, with no config on it except an IP address and a default GW. Do you get the same result?

 

 

Occasional Contributor
stavoprojekta_t
Posts: 5
Registered: ‎10-24-2013
Message 5 of 7 (304 Views)

Re: 3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

 

What does a traceroute show, from 13.15 to 14.15?

 

C:\Documents and Settings\Administrator>tracert 192.168.14.5 -d

Výpis trasy k some.sub.domain.local [192.168.14.5]
s nejvýše 30 směrováními:

1 < 1 ms < 1 ms < 1 ms 192.168.13.2
2 * * * Vypršel časový limit žádosti. ( time exceeded)
3 11 ms 10 ms 10 ms 192.168.13.2
4 * * * Vypršel časový limit žádosti.
5 * * * Vypršel časový limit žádosti.
6 * * * Vypršel časový limit žádosti.
7 * * * Vypršel časový limit žádosti.
8 * * * Vypršel časový limit žádosti.
9 * * * Vypršel časový limit žádosti.
10 * * * Vypršel časový limit žádosti.
11 * * * Vypršel časový limit žádosti.
12 * * * Vypršel časový limit žádosti.
13 3 ms < 1 ms < 1 ms 192.168.14.5  

(after some time it reaches it - probably some ICMP redirect?)

 

 

What does a "show ip rout" show, for each RouterA & RouterB?

for 3CREVF100-73 it is not possible to logon via ssh or telnet so only from GUI:

192.168.13.2 - 3CREVF100-73:

Route

Display Interface Name Destination  Mask          Gateway      Metric Flag

eth0.7 (VLAN7/WAN1)    46.x.x.0     255.255.255.0 0.0.0.0       0      C

eth0.1 (VLAN1/LAN)     192.168.14.0 255.255.255.0 192.168.13.1  1      S

eth0.1 (VLAN1/LAN)     192.168.13.0 255.255.255.0 0.0.0.0       0      C

eth0.7 (VLAN7/WAN1)    0.0.0.0      0.0.0.0       46.x.x.x      0      S

Flag: C - Directly Connected, S - Static, R - RIP, I - ICMP Redirected

 

192.168.13.1 - linux router

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.13.2 0.0.0.0 UG 0 0 0 eth0

 

 

What does a "route print" show, on PC_A, immediately after you've tried the ping?

immediatelly after ping:

===========================================================================
Aktivní směrování:
Cíl v síti      Síťová maska    Brána         Rozhraní      Metrika
0.0.0.0         0.0.0.0         192.168.13.2  192.168.13.15 10
23.63.80.60     255.255.255.255 192.168.13.2  192.168.13.15 1
127.0.0.0       255.0.0.0       127.0.0.1     127.0.0.1     1
192.168.1.60    255.255.255.255 192.168.13.2  192.168.13.15 1
192.168.13.0    255.255.255.0   192.168.13.15 192.168.13.15 10
192.168.13.15   255.255.255.255 127.0.0.1     127.0.0.1     10
192.168.13.255  255.255.255.255 192.168.13.15 192.168.13.15 10
224.0.0.0       240.0.0.0       192.168.13.15 192.168.13.15 10
255.255.255.255 255.255.255.255 192.168.13.15 192.168.13.15 1
Výchozí brána: 192.168.13.2
===========================================================================
Trvalé trasy:
Žádné

 

After 13th traceroute retry and sucesfull ping route print show this:

===========================================================================
Aktivní směrování:
Cíl v síti      Síťová maska    Brána         Rozhraní      Metrika
0.0.0.0 0.0.0.0 192.168.13.2    192.168.13.15               10
23.63.80.60     255.255.255.255 192.168.13.2  192.168.13.15 1
127.0.0.0       255.0.0.0       127.0.0.1     127.0.0.1     1
192.168.1.60    255.255.255.255 192.168.13.2  192.168.13.15 1
192.168.13.0    255.255.255.0   192.168.13.15 192.168.13.15 10
192.168.13.15   255.255.255.255 127.0.0.1     127.0.0.1     10
192.168.13.255  255.255.255.255 192.168.13.15 192.168.13.15 10
192.168.14.1    255.255.255.255 192.168.13.1  192.168.13.15 1
192.168.14.5    255.255.255.255 192.168.13.1  192.168.13.15 1
224.0.0.0       240.0.0.0       192.168.13.15 192.168.13.15 10
255.255.255.255 255.255.255.255 192.168.13.15 192.168.13.15 1
Výchozí brána: 192.168.13.2
===========================================================================
Trvalé trasy:
Žádné

 

 

Connect another device on the 13.0/24 network on the same hub as PC_A - something like a switch, with no config on it except an IP address and a default GW. Do you get the same result?

 

from LInux 192.16á.13.4 pinging 192.168.14.4 works (after first redirect)

net:~# ping 192.168.14.4
PING 192.168.14.4 (192.168.14.4) 56(84) bytes of data.
From 192.168.13.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.13.1)
64 bytes from 192.168.14.4: icmp_seq=3 ttl=127 time=0.441 ms
64 bytes from 192.168.14.4: icmp_seq=4 ttl=127 time=0.671 ms
64 bytes from 192.168.14.4: icmp_seq=5 ttl=127 time=0.442 ms
64 bytes from 192.168.14.4: icmp_seq=6 ttl=127 time=0.442 ms

 

So it looks like for me, that Windows XP (.13.5 does not accept ICMP redirect) What other I should try on WIndows XP machine? It is in VMWARE 5.0 ESX.

 

 

Trusted Contributor
Vince_Whirlwind
Posts: 401
Registered: ‎02-25-2013
Message 6 of 7 (297 Views)

Re: 3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

I wonder if the VMWare switch is the problem. You could add a host route pointing at 13.1 for 14.0/24.

 
 

Personally, rather than try to fix this in the host,  I would change the network around so either

 - your hosts on 13.0/24 have just one router, ie, change the link between your two routers to be a new and different subnet dedicated to this link and get rid of the 13.0 interface off one of the routers.

or

 - move your hosts to a new subnet and choose one of the two routers to route for that subnet.

Occasional Contributor
stavoprojekta_t
Posts: 5
Registered: ‎10-24-2013
Message 7 of 7 (291 Views)

Re: 3CREVF100-73 - HP OfficeConnect GbE VPN Firewall (JC206A) - routing problem to another network

[ Edited ]

> I wonder if the VMWare switch is the problem. You could add a host route pointing at 13.1 for 14.0/24.

Maybe, but now I remembered that we have some simple network devices pointing to GW 13.2 which cannot route to 14.0/24 - because (probably - IMHO) 3CREVF100-73 (13.2) does not forward packets to second router (13.1)

 
 

> Personally, rather than try to fix this in the host,  I would change the network around so either

 - your hosts on 13.0/24 have just one router, ie, change the link between your two routers to be a new and different subnet dedicated to this link and get rid of the 13.0 interface off one of the routers.

or

That would be nice and I would like to do this way as You say "to have just one router".

3CREVF100-73 can separate LAN into subnets and VLANs, BUT it cannot route between them - so it is unusable and I had to use second router :-(

See my other post here: http://h30499.www3.hp.com/t5/LAN-Routing/Inter-Vlan-routing-is-not-working-in-3CREVF100-73/td-p/6246...

 

 - move your hosts to a new subnet and choose one of the two routers to route for that subnet.

 

 

I hate 3CREVF100-73 - it is crap with many bugs. Unfortunatelly we bougth many pieces so have to use it.

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.