Router listening on public interface?

[obochkis]

I have two Windows Boxes connected to RV042 ; each has its own static IP assigned to it and each runs bunch of virtual machines , for which I had configured port forwarding .

My hosting company claims that my server(s) are listening on IP 192.168.0.1 on a public interface (i.e., one that uplinks to their network). They see this same IP on two different MACs my uplink interface.  I am not really sure how it is possible since 192.168.0.1 was assigned to router itself.   They are threatening to disconnect us, so any help will be appreciated.

[fabios]

Oleg,

I do not understand the bit concerning the MAC address.

Plese explain how do you connect to the Internet. Also are you "listening" or leaking 192.168.x.x?

About the listening, if they route to you a packet addressed for an IP address the router is configured with, the router will reply, but according to its routing table.

I.e. if 192.168.0.1 is configured on the Ethernet0 Interface and a ping for that address arives on serial 0 the reply will go out on ethernet0.

The best way of preventing RFC1918 traffic to come in (and also a good security practice) is to filter that one out with an access list as follows:

deny ip any 192.168.0.0 0.0.255.255

deny ip any 10.0.0.0 0.255.255.255

deny ip any 172.16.0.0 0.15.255.255

(the rest of you security access-list here if none add a permit any any)

and apply this access list to your internet facing interface with an access group [list name|number] in

hope this helps

Fabio

[obochkis]

They (hosting compony) ran

#arping -c 5 -i eth1 192.168.0.1 | grep c4:71:fe:bd:90:ab on their network

And got:

60 bytes from c4:71:fe:bd:90:ab (192.168.0.1): index=2 time=344.992 usec

60 bytes from c4:71:fe:bd:90:ab (192.168.0.1): index=7 time=380.039 usec

60 bytes from c4:71:fe:bd:90:ab (192.168.0.1): index=11 time=277.996 usec

60 bytes from c4:71:fe:bd:90:ab (192.168.0.1): index=17 time=338.078 usec

60 bytes from c4:71:fe:bd:90:ab (192.168.0.1): index=22 time=386.953 usec

#arping -c 5 -i eth1 192.168.0.1 | grep c4:71:fe:bd:90:ac

60 bytes from c4:71:fe:bd:90:ac (192.168.0.1): index=3 time=435.114 usec

60 bytes from c4:71:fe:bd:90:ac (192.168.0.1): index=8 time=422.955 usec

60 bytes from c4:71:fe:bd:90:ac (192.168.0.1): index=13 time=374.794 usec

60 bytes from c4:71:fe:bd:90:ac (192.168.0.1): index=19 time=465.870 usec

60 bytes from c4:71:fe:bd:90:ac (192.168.0.1): index=23 time=397.921 usec

Where c4:71:fe:bd:90:ab and c4:71:fe:bd:90:ac are MACs of WAN ports on my RV042. I am not really sure why they are responding  to arping but I need to stop it.

[cadet alain]

Hi,

Just a thought, is proxy-arp enabled on these interfaces by any chance ?

Regards.

Alain.

[cadet alain]

Hi Fabios,

fabios a écrit:
Oleg,
I do not understand the bit concerning the MAC address.
Plese explain how do you connect to the Internet. Also are you "listening" or leaking 192.168.x.x?
About the listening, if they route to you a packet addressed for an IP address the router is configured with, the router will reply, but according to its routing table.
I.e. if 192.168.0.1 is configured on the Ethernet0 Interface and a ping for that address arives on serial 0 the reply will go out on ethernet0.
The best way of preventing RFC1918 traffic to come in (and also a good security practice) is to filter that one out with an access list as follows:
deny ip any 192.168.0.0 0.0.255.255
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
(the rest of you security access-list here if none add a permit any any)
and apply this access list to your internet facing interface with an access group [list name|number] in
hope this helps
Fabio

If you apply this ACL ingress on internet facing interface then it will prevent any src address going to the rfc1918 addresses and so will prevent a regular ping to 192.168.0.1 to succeed but not the arpings as they use arp request which is different ethertype from IP. Furthermore these addresses are not routeable on the internet so the antispoofing type of ACL you are talking about is using src add for rfc1918 and not dest as you did.

It seems the ISP is on the same L2 broadcast domain as the router, what sort of ISP connection is it?

Regards.

Alain.

[fabios]

Hi Alain,

you are certainly right.

In his original post Oleg did mention MAC address (which I did not understood) and di not explain how he is connected to the ISP. I did ask the question and he did not provide the detail.

Also I asked if he had followed the initial suggestions to undestand what wa going on.

While true that those address are not routable on the internet, many ISP (mine also) route those in their infrastructure (I have a dsl connection and my DSLAM is 192.168.100.1) so the ISP can actually souce a regular ping from the DSLAM and send it out over a point to point link without routing rfc1918 addresses.

This said, leaking MAC address means that ISP and CPE router are on same broadcast domain (also the use of ARPING from ISP on customer links is symptomatic).

Still I do not understand why:

-cutomer has to manage his router if under same broadcast domain of ISPs';

-if this is a problem customer does not ask ISP to support;

-IPS instead of ofering advice threatens to disconnect.

Let's wait and see.

Cheers

Fabio

[fabios]

Oleg,

Did you apply the access list I suggested?

Do you still have the problem after that?

Fabio

Sent from Cisco Technical Support iPhone App

[obochkis]

Hi. yes I did but I have not tested it yet - I need to be on site to do that. Hopefully I can do it today.