BrunoVic

Members
  • Posts

    84
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

BrunoVic's Achievements

Rookie

Rookie (2/14)

1

Reputation

  1. Ok I think I figured out why I couldn't remove those static routes. User error I forgot to turn off docker. So once docker is off I cleaned up the routing table the way I liked it turned docker back on and everything is working as I would like it. I did notice however once the network daemon restarts it will rebuild the routing table with those static routes that I do not want. Is there a way to stop that from happening?
  2. Yes different subnets do access the gui. But that's because I am allowing it for now through the firewall. I plan on forcing all gui traffic to go to the server vlan ip address which is the 30.5 ip. The reason I have the other VLANs has more to do with what I am trying to do with my unifi docker container trying to implement multi vlan wifi networks. That a whole completely different topic on it's own. But for the purposes of management and smb all I want is for ALL networks to access 30.5 and nothing else.
  3. Oh and the interVLAN routing is done on the pfSense not the UNRAID. I don't expect the UNRAID to do any routing other than static routes to their respective networks. The interVLAN is working flawlessly. The problem is that UNRAID can't make up it's mind as to which destination it wants to send the traffic to. From the looks of it what I ultimately want done is I want to re-enable VLAN20 but I DON'T want a static route put in the routing table for VLAN20. I need ALL default routes to go to the 30.0/24 interface. Unfortunately I cannot delete those static routes for some reason.
  4. It's a problem with the routing table. I did an experiment and it worked now my problem is why is it doing that. So what I did was I disabled the VLAN 20 interface more or less by not configuring an IP at all. When the network daemon restarted it rebuilt the routing table and excluded the 20.0/24 network. Now when I do a transfer from 30.0/24 to 20.0/24 the transfer is successful without any issues. Problem is I need that VLAN 20. So the moment I bring it back up I will have the same problems again. It looks like for some reason when the transfer is first started it chooses the default path but for some reason it later decides to send it to the 20.0/24 interface but the client is expecting the response to be from a 30.5 host not a 20.5 host so it essentially times out. Even with the default route set to a metric of 1 which SHOULD be preferred over the 20.0/24 route it still wants to send the traffic to a dead end destination and I do not know why.
  5. I stumbled and hijacked this thread. Not sure what the proper etiquette is here on that. But seeing what this guy is going through it seems very similar but not exact. He never really posted his routing table. He said he noticed something wrong with it but without any further details I can't figure what exactly his solution did for him that helped. I looked at my routing table and eliminated any unnecessary default routes. In networking when dealing with multiple networks you only need ONE default route. I am not sure why creating a VLAN interface made that much of a mess with the routing table. Even then though after cleaning everything up I am still having the same problem. I can't help but feel I am so close to a solution though. I have a feeling it has something to do with the routing table but I can't quite figure out what is wrong. If I were looking at a Cisco router everything would look fine right about now. But this is a UNIX like system so I am in uncharted territory.
  6. What did your routing table look like before. I am having almost identical issues as you. Same subnet and transfer is fine. Different subnets and transfer works for about a few seconds but then dies. I looked at my routing table and I had a bunch of default routes I had to clean up. Looks like they were auto generated with the VLAN interfaces. Unfortunately even after cleaning everything up I am still having the same problems as you. I'll attach a screenshot of my routing table. Maybe another set of eyes on this may give me a clue.
  7. Guys please ask me some probing questions at least. I've provided diagnostics reports and I have posted follow up thread of my TS efforts on the network side. I don't know much on the server side and I am deferring to you for help. But if I am the only one asking my own questions I am simply chasing my tail here. So what information can I provide to you guys that can help us find a resolution here?
  8. Ok so I figured out my route metric problem. Seems I had the VLAN interface configured to static IP which kept forcing a route metric of one. Now that is adjusted the only route metric of 1 on the VLAN interfaces is 172.28.30.0/24. I though this would have fixed my issues but it looks like that did not fix it. So why is it that anything I transfer from the 30.0/24 network to the 20.0/24 network I get an error but from the 20.0/24 network and the 20.0/24 network it works fine?
  9. I have a strong feeling this is the problem. For some reason the metric on 172.28.20.0/24 is set to 1. I've manually set the metric to 233 on the VLAN interface but for some reason there is still a static route set to 1 that will not budge and it's creating all kinds of issues for 172.28.30.0/24. Why can't I delete the static route for 172.28.20.0/24?
  10. Anyone have any ideas on this? I still haven't been able to fix this.
  11. So has anyone else had experience with this? Why is the connection intermittent when transferring from a different subnet and there is no connection problem transferring from the same subnet?
  12. Ok I think I may have narrowed down the culprit but now I need to know WHY. Right now UNRAID is sitting on a server network which is a different network than the user network that I am on. I have multiple VLANs on the UNRAID host. When I try to transfer data from UNRAID on the server VLAN to a computer on the user VLAN the network connection is constantly dropping. However if I transfer data from UNRAID on the user VLAN to a computer on the user VLAN (same network) there is no problem with the connection. So I know what you are going to say. Then just use the user VLAN and problem fixed right? Wrong the whole point of putting the UNRAID on a different network from the user network is so that if one network is compromised then the user network is still protected. However if the UNRAID is on the same network as the users then there is a potential that if UNRAID is compromised then the computer on the same network will be compromised as well and vice versa. So I need to figure out WHY the connection keeps dropping out when transferring the files from one different subnet to another?
  13. Ok so even with WinSCP I am still getting connection drops to the unraid server.