pfSense English Support > Routing and Multi WAN

Trying to connect from main network into subnet.

(1/3) > >>

Buayaguy:
Hi all,

I've been setting up home routers for a long time, but it's always been simple stuff - I've never tried connecting multiple subnets before, and am setting up a little virtual lab to learn more in-depth networking topics.

Setting up pfSense was simple, and the subnet it's using (10.0.0.0/24) had zero problems immediately being able to access the Internet.

I'm trying to start simple. So I have my iMac, which is my *primary* computer - I access my virtual PCs through it as well, so pretty much everything I see on screen is coming through this computer.

You can see in the diagram below my basic setup (I'll be adding more later, but again, I just want to make sure *both* subnets can talk to each other at this point.)

Right now, I want my iMac and my Windows 10 VM (10.0.0.3/24) to be able to talk to each other. It's halfway there.

Windows 10 can successfully ping (and even log into all of) my primary router (192.168.1.1/24), my iMac (192.168.1.5/24) and my NAS (192.168.1.3/24).

The iMac can't seem to ping anything in the 10.0.0.0/24 subnet without some kind of issue.

Here's what it can do right now:


--- Code: ---$ ping -c 4 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.168 ms
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 c368   0 0000  3f  01 ec92 192.168.1.5  10.0.0.1

64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.818 ms
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 504b   0 0000  3f  01 5fb0 192.168.1.5  10.0.0.1

64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.646 ms
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 20a0   0 0000  3f  01 8f5b 192.168.1.5  10.0.0.1

64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.709 ms

--- 10.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.646/0.835/1.168/0.202 ms
--- End code ---


--- Code: ---$ ping -c 4 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 3a69   0 0000  3f  01 7590 192.168.1.5  10.0.0.3

Request timeout for icmp_seq 1
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 275a   0 0000  3f  01 889f 192.168.1.5  10.0.0.3

Request timeout for icmp_seq 2
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 ccfb   0 0000  3f  01 e2fd 192.168.1.5  10.0.0.3


--- 10.0.0.3 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
--- End code ---


I've never seen a Redirect Host message EVER when I ping anything - The first example had 0% packet loss, but the second had 100% packet loss - what's going on here?



My iMac *can* access the *server* computer (192.168.1.200), since it has a direct connection back to my router (192.168.1.1) (and which I would
assume is why my VMs can access the Internet.)

But for some reason it *can't* access the WAN side of the pfSense link, even though it's on the 192.168.1.x side.


--- Code: ---$ ping -c 4 192.168.1.201
PING 192.168.1.201 (192.168.1.201): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

--- 192.168.1.201 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
--- End code ---


Thinking that maybe there was a firewall issue, I added the 2nd rule in the WAN section of pfSense, but otherwise all the WAN and LAN rules are default.

So I guess the ultimate question here is - what's stopping me from being able to get INTO 10.0.0.0 (and in this example, stopping me from at least being able to ping 10.0.0.3)?

I'm pretty much at a loss at what to do next - any help would be *extremely* appreciated.

Thanks,

       -Bryan



Edit: Should be obvious at this point, but my chart forgot to show that my pfSense WAN IP does have a /24 subnet mask (192.168.1.201/24)

tmack8080:
As far as accessing your WAN interface from the same segment, i.e., 192.168.1.0 - I suggest you open up your firewall rule just to test. See attached. I was not able to ping my WAN interface until I did that.

Buayaguy:
Well that was a huge help, thank you :)

I still don't want to leave it *completely* open (I know I'm still behind my main router's firewall, but this is to test how secure I can be while still having access myself.)

Opening it up worked, but then I altered it slightly, and then came up with a second rule to access the other *subnet* directly (10.0.0.0/24)

Rather than leaving the destination completely open (*), I set it to WAN Net, which still allows me to ping my 192.168.1.201 (pfSense's WAN address)

I also set up this little alias so my source is literally all 3 of my networks, so everything I have can connect through it (my 172.16.x.x needs to be reinstalled, but just knowing I can ping and *access* pfSense through web interface on 192.168.x.x was a major accomplishment for me, thank you.)

The other rule to 10.0.0.0/24 allows my iMac to ping and have web interface pfSense access on the 10.0.0.1 LAN interface as well.

The *only* thing I still can't seem to do is ping my Windows 10 VM at 10.0.0.3...


--- Code: ---$ ping -c 4 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 3fcc   0 0000  3f  01 702d 192.168.1.5  10.0.0.3

Request timeout for icmp_seq 1
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 2e50   0 0000  3f  01 81a9 192.168.1.5  10.0.0.3

Request timeout for icmp_seq 2
92 bytes from netgear (192.168.1.1): Redirect Host(New addr: 192.168.1.201)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 3a70   0 0000  3f  01 7589 192.168.1.5  10.0.0.3


--- 10.0.0.3 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
--- End code ---

Once I can do that, I think I'll have all the rules in place to be able to access ANY of my other machines on 10.0.0.0/24, and use these same rules
to set up my 172.16.1.0/24 network.

Any ideas why the ping to Windows doesn't work?

Thanks again, you've been an awesome help, great birthday present for me today :)

         -Bryan
 

Buayaguy:
Quick update - Still not sure what's going on with the ping stuff, but I tried booting up my Linux server VM, and with the rules I put in place earlier, it looks like I *DO* have access into the 10.0.0.0 network from 192.168.1.0 -- I was able to successfully ssh into my Linux box from the iMac, so I guess those may be the only firewall rules I need.

That ping is still bugging me, although I know it's obviously not the only method of checking connectivity...

Derelict:
First, you have an asymmetric routing problem.

The default gateway for the mac is the netgear so all traffic for 10.0.0.0/24 gets sent there first. That is why you are seeing the ICMP redirects. That is lousy design.

A better way would be to make another router interface on the netgear to connect only to the pfSense WAN interface on another subnet. See the attached image. It is not identical to your situation but it demonstrates the problem.

You should probably disable outbound NAT on pfSense too. Set advanced/manual mode there then disable all of the rules.

Is the windows firewall enabled on host 10.0.0.3?

Navigation

[0] Message Index

[#] Next page

Go to full version