Verizon CR200a in ip passthrough?
-
Hmm, so with the policy routing rule sending al traffic from the test host via the DSL WAN you are still seeing some issues connecting from that?
-
@stephenw10 said in Verizon CR200a in ip passthrough?:
Hmm, so with the policy routing rule sending al traffic from the test host via the DSL WAN you are still seeing some issues connecting from that?
@Elmojo said in Verizon CR200a in ip passthrough?:
With the rule in place, and the Verizon gateway set as default, my desktop works...sorta. Youtube videos play, but my ZeroTier tunnel is still broken
No, if I enable that policy routing rule, then my desktop mostly works. But that's just a temporary test, since the idea is for eventually the DSL WAN to go away, and only to have the Verizon WAN.
It appears that whatever the issue is, it's some sort of conflict between the Verizon ISP and the configuration of my desktop. I just can't imagine what it would be. I've tried changing my DNS servers back to defaults, turning my software firewall off, and even disabling my antivirus temporarily. None of it makes any difference.
-
Right. But that fact that test host doesn't work it did before even when it's traffic is routed via DSL implies the problem could be due to the existence of the dual WANs rather than which WAN it's using.
For example if the DNS is broken because that is all going via WAN2.
You see all configured DBS servers responding in Diag > DNS Lookup still though?
-
@stephenw10 said in Verizon CR200a in ip passthrough?:
For example if the DNS is broken because that is all going via WAN2.
WAN2 being the new Verizon ISP?
I'm not sure what exactly I'm seeing when I perform a DNS lookup. This looks weird to me. Does it look correct to you?
I mean, should I be seeing the localhost address under the name server?
-
Yes localhost is the default. That means the system queries Unbound running locally.
The slightly odd thing there is that there are no other DNS servers set. Usually servers would be passed to the system from the ISP when the WAN connects via DHCP or PPPoE. So in your case I'd expect to that from both WANs.
-
@stephenw10 Where would you expect the DNS servers to be set? Is that something that I would have config'd in unraid, in pfsense, or on an individual machine? I am running specific DNS servers on my desktop (adguard for ad blocking), but I don't recall setting anything special anywhere else. If I was ever asked to specify DNS servers, it would have been either Google (8.8.8.8/8.8.4.4) or maybe Cloudflare (1.1.1.1).
-
I expect them to be passed to pfSense over DHCP or PPPOE when they connect. That wouldn't happen if your WANs are both statically assigned?
-
@stephenw10 said in Verizon CR200a in ip passthrough?:
I expect them to be passed to pfSense over DHCP or PPPOE when they connect. That wouldn't happen if your WANs are both statically assigned?
So they should be automatically assigned by the ISP(s)? Is there any way for me to check?
-
You should see them in Status > Interfaces on the WANs like:
However this should wok fine with only the local resolver. The only reason it may not is because that will use the default route to reach the root servers and that has now changed to WAN2.
-
@stephenw10 Weird, no mention of DNS on either WAN.
I'm not sure I quite follow your 2nd statement. Are you saying it's trying to use the DNS servers from my original WAN, but it's connecting through the new Verizon WAN, and getting confused?
-
Well that's odd that neither DHCP server passes any DNS server to use but that shouldn't cause an issue by itself.
The DNS resolver (Unbound) should always work. But what may have changed here is that traffic from Unbound is now using WAN2.
So one thing you can try is setting the outbound interface Unbound is using using in Services > DNS Resolver. If you set that to WAN (DSL) instead of all that puts the system back in the same conditions it was before adding the second WAN. The test host being routed via DSL should work as before at that point.
-
@stephenw10 I'll give that a try, thanks. Would you suggest leaving the routing rule in place, or removing it temporarily while testing the DNS thing?
If I leave it in please, I'm thinking we won't know which one is fixing the trouble, since everything is working fine right now, with the rule active...
Is that wrong? -
I would leave the rule in place initially.
If moving the outgoing DNS to the old WAN appears to fix things then try disabling to the policy routing rule and see if it's still good. I doubt it will though TBH
-
@stephenw10 said in Verizon CR200a in ip passthrough?:
If you set that to WAN (DSL) instead of all
OK, done.
Confirmed that with the policy routing rule in place, all works fine.
With that rule removed, youtube is instantly broken again.
I'm a little confused about what the DNS change tells us, since things are working fine with only the policy rule, and break without it.
Is any of this informing you of what the issue may be? -
Oh, I'm sorry too many threads! I got confused there.
Ok, then with the DNS moved to the DSL WAN does the problem still return if you disable the policy rule? Or just test from a different host that isn't using the rule?
-
@stephenw10 said in Verizon CR200a in ip passthrough?:
with the DNS moved to the DSL WAN does the problem still return if you disable the policy rule? Or just test from a different host that isn't using the rule?
So I learned something last night.
With the policy rule in place (only affecting my Desktop PC of course) and the outgoing DNS resolver set to WAN only, everything works fine on my machine.
However, my wife was trying to watch a video on a site for work (not youtube), and it would not play on her Desktop or her iPad until I changed the default gateway under System->Routing back to WAN (dsl), then it worked fine again.
There definitely appears to be some issue with the Verizon WAN and certain video streaming services. -
@Elmojo said in Verizon CR200a in ip passthrough?:
There definitely appears to be some issue with the Verizon WAN and certain video streaming services.
Yet when you connected a host to the Verizon modem directly it worked fine? It only fails like that when routed via pfSense?
-
@stephenw10 said in Verizon CR200a in ip passthrough?:
Yet when you connected a host to the Verizon modem directly it worked fine? It only fails like that when routed via pfSense?
You know, at this point I can't even recall. lol
I know we tested that earlier. It must be buried somewhere in this thread...
Ok, So I see back around post #32 where you asked me to check that, but I don't see a clear response from me as to whether I actually was able to test it that way or not. I'll check that and get back to you. -
@stephenw10 said in Verizon CR200a in ip passthrough?:
Yet when you connected a host to the Verizon modem directly it worked fine?
Short answer = yes
The Verizon gateway has 2 LAN ports. One is for "normal traffic", the other is for "admin". When I connect directly to the Verizon gateway via LAN port 1, I get IP 192.168.1.2, and I can log into the gateway UI to do admin stuff, but I have no internet access.
If I use LAN port 2 (which is the one that normally would be connected to the pfsense box), then I get an external IP, and everything (including YouTube) works fine.It does indeed seem to be something o do with pfsense, or perhaps some other aspect of my network infrastructure, although I can't imagine what else it would be.
The topology is as follows:
Verizon gateway -> Cat5e -> pfsense Verizon WAN interface (igb2)
Leaving pfsense via LAN interface (igb1) -> Cat5e -> TP-Link managed Gb switch -> rest of home networkAny of that look fishy to you?
-
@Elmojo said in Verizon CR200a in ip passthrough?:
Any of that look fishy to you?
Not beyond the fact it seems to be not passing traffic correctly.
It's odd that it would be streaming traffic like that. How exactly does it fail?
Some sites failing like that is usually either some subnet conflict, like an interface incorrectly configured as /8 or similar. Or an MTU issue when large packets fail to pass:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/website-access-issues.htmlThe other common issue is IPv6 failing and some devices preferring and therefore trying to use it. But we checked that. And also that usually presents as sites initially failing to load but then eventually loading.
Is there a site you've found that fails to load entirely? That would be much more convenient for troubleshooting.
