How to route multiple VLANS to server
-
Hello Everyone -
Please help me understand/how to network. I have a background in server administration 5+ windows at work/linux and pfsense at home. I just recently stepped in as backup admin at my current employer and things do not see correct with how everything is setup. Basically we have numerous backup servers in our 2 datacenters. All backup servers in each data center are in the same rack eg: datacenter1 has servers 1,2,3 (same rack) and datacenter2 has severs 3,4,5(same rack).
The issue is all these servers have been configured to connect to multiple VLANs around my organization via their nic cards. so:
server1 is configured to connect to VLANS 654, 765, 879, a few static routes etc..
server2 is configured to connect to VLANS 654, 765, 879, a few static routes etc..
All Server must have the same network configuration.That got me thinking about pfSense. Could I set a pfSense box ahead of these servers to handle the VLAN config?
pfSense –> VLANS 654, 765, 879, a few static routes etc..
|
|
|-----> server1, server2, server3Basically, I'm looking for a way to centralize the routing to the separate VLANS as the number of backup servers will grow. Is this a good Idea?
Thanks!
-
pfsense and/or a switch (depending on its capabilities) could handle it.
You can filter the type of traffic that passes over a vlan, so whilst it might be common for a vlan to be considered a network for all types of traffic to one or more devices, it doesnt have to be handling all traffic, it could equally be a vlan just for web traffic in, email traffic out and so on.
Whilst you might want to centralise for convenience, also consider the risks in case you get hacked. If they gained access to pfsense, both your data centres could become useless. If you have a switch managing the vlans, that switch could also make your two data centres useless. Just like virtualisation is also having all your eggs in one basket.
Sometimes physical isolation is best which could mean one or more dedicated switches which also have their login access only kept on the switch, not in any radius server on another device. The more you isolate the harder it is to get into other devices.
Your convenience is also your hackers convenience, and with so much encrypted data going over a network, unless you bruteforce decrypt it, you cant account 100% for any encrypted data moving around besides IDS/IPS systems can see into encrypted data making them somewhat useless as well.
-
I would keep backup traffic off my router and on the same layer 2 network as the systems being backed up. At least as much as possible.
-
Thanks for the quick responses. My apologies but I should have stated that everything is already firewalled from the WAN between my 2 data centers. So my entire backup infrastructure is already protected. I was just curious if pfsense (no firewall enabled) would be good to use in my situation for connecting my backup servers across these different VLANS. With that said, would a switch be more appropriate?
-
So you have a single firewall setup and not a dual firewall setup? https://en.wikipedia.org/wiki/DMZ_%28computing%29#Dual_firewall
I'd use pfsense to make it a dual firewall setup, because if your 1st fw is not using freebsd then mixing up the OS's also helps reduce risks caused by using all the same OS's.
You might also have a firewall setup on the devices themselves, but as we see with this bug http://www.theregister.co.uk/2015/10/29/xen_security/
its a seven year old bug so you can never be too careful.and by now you should be getting used to the x86-operating-system circle of Hell. It's possible, as an attacker, to evade these checks and flip the right bits to gain read-write access to the system's level one page table – the world map of the host's memory. It allows the guest to access any part of the system RAM.
It's game over at that point
I've always liked ARM processors.
Bugs are potential zero days, and the more bugs you can find in a device the greater your chance of being able to hack a device.
Ultimately the choice is yours, your aim is to reduce the theoretical risks as much as possible.
-
Having a hard time with your ascii art.. Can't you just grab a napkin and crayon and snap a picture with your phone? Worse case???
"All Backup servers have access to the various VLANs via their onboards NIC's"
So you have your nics with multiple IPs on them?? Confused by this statement.. Can you not just post output of ipconfig /all or ifconfig off these backup servers? Or do you have multiple nics?
You talk about routing on backup servers? Why would they have routes? Why would they not just talk to their gateway to get to whatever servers they want to backup?? Why would they need routes added??
As to having a backup network – yes its common for have extra nic on servers that is tied to the backup network so all this traffic does not flow over the production network and yes is common for this to be a common Layer 2 so you don't have to route traffic..
It really sounds like your not actually routing anything and just multihoming into multiple networks?
-
Makes no sense at all.
-
So I am not just having a senior moment then ;) Its just a lot of gibberish is it not??
"All Backup servers have access to the various VLANs via their onboards NIC's and we establish networking with the use of DNS eg: VLAN 22 has a host entry of Backup1_V22.domain.com, Backup2_V22.domain.com, etc…"
But he shows servers only in one vlan... But then states "we have to add the subnets to each backup server on the appropriate network connection"
-
LMAO ;D thanks for the feedback. I stated that I was no networking expert. I decided to remove that post as it was full of fail and confusion. I guess I'm just really don't fully understand my current network setup. I have been told that it is the network that keeps on giving.
I cleaned up my art. The original preview looked amazing as with most movies these days. ;D Probably still doesn't make sense!
Yes each server has multiple virtual nics (one for each VLAN assignment along with an IP that resides in that particular VLAN).
"You talk about routing on backup servers? Why would they have routes?" I believe static routes were added because of the subnet extensions to the VLANS. So we have a route to VLAN87 10.19.46.0/24, but another subnet 10.19.47.0/24 was added to that VLAN. I guess we need add a static route to 10.19.47.0/24 so the backup server can see the hosts on that subnet.
Also, each backup server connected to multiple sub-domains:
The DNS lookup order on the NIC is:
subDOMAIN1.private.fun.com
subDOMAIN1.backnet
subDOMAIN2.fun.com
etc."It really sounds like your not actually routing anything and just multihoming into multiple networks?" Yes this is exactly what we are doing.
-
"Yes each server has multiple virtual nics (one for each VLAN assignment along with an IP that resides in that particular VLAN)."
So these servers are virtual?? How many physical hosts??
"Yes each server has multiple virtual nics (one for each VLAN assignment along with an IP that resides in that particular VLAN)."
So you just completely made your vlan firewalls completely POINTLESS!!!!
""It really sounds like your not actually routing anything and just multihoming into multiple networks?" Yes this is exactly what we are doing."
Then WHY the routes??? This makes NO sense - see attached. What is the point of vlan 1567 that only has a vlan 22 ?? What are the networks of these vlans? Why don't you points the output of either ipconfig /all and or ifconfig of these servers.. Vlan ID numbers are completely pointless are are most the time arbitrary numbers so those are going to have little meaning to someone trying to help you..
Also the subdomains and domain name you are pointing again have NOTHING to do with the actual network.. Is just a name you resolve to an IP that has nothing to do with the actual network… Does not matter what FQDN you use, does not matter if they are sub domain of sub of subs, etc. etc..
Do you have nat going on anywhere?? Other than at the firewall/router to the internet??
-
These are all physical servers:
Windows IP Configuration
Host Name . . . . . . . . . . . . : backup_server
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : accounting.private
informationtechnology.fun.com
accounting.fun.com
sales.fun.com
shipping.fun.com
fun.comEthernet adapter Ethernet:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_1270
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server.PrivateIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_37 (accounting Private):
Connection-specific DNS Suffix . : accounting.private
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_37 (accounting Private)
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server.accounting.private.PrivateIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.0.93
192.168.0.94
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_46:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_46
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server_VLAN_46.PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 1297028610
DHCPv6 client DUID. . . . . . . . : 11-03-00-03-1A-BY-37-67-A0-87-2B-53-55-12P
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_87:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_87
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server_VLAN87.PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : DisabledEthernet adapter VLAN_88:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_88
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::312e:3dc9:7401:b5c6%25(Preferred)
IPv4 Address. . . . . . . . . . . : backup_server_VLAN_88.PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 465900123
DHCPv6 client DUID. . . . . . . . : 11-03-00-03-1A-BY-37-67-A0-87-2B-53-55-12P
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_45:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_45
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server_VLAN45_PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_251:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_251
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server_VLAN_251.PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_7 (accounting Local):
Connection-specific DNS Suffix . : accounting.local
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_7 (accounting Local)
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server.accounting.local.PrivateIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 84632670
DHCPv6 client DUID. . . . . . . . : 11-03-00-03-1A-BY-37-67-A0-87-2B-53-55-12P
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN_12 (accounting Public):
Connection-specific DNS Suffix . : accounting.fun.com
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter - VLAN : VLAN_12 (accounting Public)
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server.accounting.fun.com.PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : 67.8.214.1
DNS Servers . . . . . . . . . . . : 67.8.3.21
67.8.3.22
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter VLAN7_Public_1G:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Gigabit 4P I670-t rNDC
Physical Address. . . . . . . . . : EC-G6-AA-G5-47-76
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : backup_server_VLAN7_Public_1G.PublicIP(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.224
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 67.8.3.22
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter Intel_10G_2P_X520 SLOT 5 Port 1:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet 10G 2P X520 Adapter #2
Physical Address. . . . . . . . . : P0-36-5F-50-66-78
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.{D66FDEB0-DF33-4100-8B05-CB7FFC9W0BCD}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.{60C56E22-533E-4891-914F-E5D1868BA78C}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.{E75E5215-5B53-421Q-AD79-F2463D366A98}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter 6TO4 Adapter:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft 6to4 Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 1003:4804:d7b::4804:d7b(Preferred)
IPv6 Address. . . . . . . . . . . : 1003:4804:710e::4804:710e(Preferred)
IPv6 Address. . . . . . . . . . . : 1003:4805:2e5::4805:2e5(Preferred)
IPv6 Address. . . . . . . . . . . : 1003:4805:f025::4805:f025(Preferred)
IPv6 Address. . . . . . . . . . . : 1003:4805:f0e3::4805:f0e3(Preferred)
IPv6 Address. . . . . . . . . . . : 1003:4805:f257::4805:f257(Preferred)
IPv6 Address. . . . . . . . . . . : 1003:4805:f41b::4805:f41b(Preferred)
Default Gateway . . . . . . . . . : 1003:c058:6301::c058:6301
DHCPv6 IAID . . . . . . . . . . . : 3678012
DHCPv6 client DUID. . . . . . . . : 11-03-00-03-1A-BY-37-67-A0-87-2B-53-55-12P
DNS Servers . . . . . . . . . . . : 67.8.3.21
NetBIOS over Tcpip. . . . . . . . : DisabledTunnel adapter isatap.{C7BDA31D87CE-FG07-4360-4378-E759DFEC5D48}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #4
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.{EED10679-653A-46B5-B72F-E80D0873}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #5
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.accounting.local:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : accounting.local
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #6
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.accounting.fun.com:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : accounting.fun.com
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #7
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.accounting.private:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : accounting.private
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #8
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.{FP00097E-70BF-4017-8B41-38F47B4GGG67}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #9
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesTunnel adapter isatap.{672GC442-05C0-4450-BC79-EC9B10PQB80B}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #10
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-A0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes -
What a F_cking MESS!!! REally????
So did time warner give you a bunch of space? You have those public 67.x address that are owned by time warner
NetRange: 67.8.0.0 - 67.11.255.255
CIDR: 67.8.0.0/14
Organization: Time Warner Cable Internet LLC (RRSW)You have ipv4 addresses with IPV6 dns (anycast) and no gateway on that interface, 6to4 with a bunch of ipv6 that has ipv4 dns
So you also have IPs from quest?
NetRange: 67.12.0.0 - 67.13.255.255
CIDR: 67.12.0.0/15
Organization: Qwest Broadband Services Inc. (QBS-12)And Tmobile
NetRange: 172.32.0.0 - 172.63.255.255
CIDR: 172.32.0.0/11
Organization: T-Mobile USA, Inc. (TMOBI)Then you have stuff where you have a gateway that is not even in the same segment
IPv4 Address. . . . . . . . . . . : 67.8.215.18(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : 67.8.212.1Who setup such a MESS??? Dude it really should just be scrapped and done correctly.. Do these server need to be accessed remotely?? Why do they have public and private IPs on them? With all kinds of different masks and dns??
If you they need to be accessed remotely - why are they in a public network segment without a gateway??
If your going to be using 6to4 since you have a bunch of addresses on it, why do you have isatap and teredo still enabled?
Really just from that output I would say your whole network needs to be scrapped and done with some kind of actual order.. There should be no reason these servers have so many interfaces!!!
-
Yeah, what a mess, why's that thing multihomed to ~10 different networks? You should use the router/managed switch to route packets between those! Plus: use GPO to disable the IPv6 transitional shit globally, or netsh on each machine.
netsh int ipv6 isatap set state disabled netsh int ipv6 6to4 set state disabled netsh interface teredo set state disable
your whole network needs to be scrapped and done with some kind of actual order.. There should be no reason these servers have so many interfaces!!!
^^^ this. Not manageable at all. Not worth debugging.
-
So did you try and obfuscate stuff? This is not a valid mac
Physical Address. . . . . . . . . : T0-78-2P-67-66-11D
Who set this nonsense up?? Really they clearly understand less about networking than you do ;)
So is there really another X520 nic and your just not using, but creating multiple vlans all over 1 nic.. Then there is some other nic, that also not valid
Description . . . . . . . . . . . : Intel(R) Gigabit 4P I670-t rNDC
Physical Address. . . . . . . . . : EC-G6-AA-G5-47-76And it has no gateway on it?? But dns setting not in that segment.. So how exactly is it suppose to get to that dns?
The more I look at this the more of a cluster it seems to be.. So since you were drawing ascii art to try and describe this mess, I take it there is no actual drawing either???
In all honesty from looking at just the output of 1 server.. Someone needs to be FIRED!!! They are clearly way way way over their head in network setup..
-
Wow, thanks again for the feedback. I was feeling pretty dumb the last few weeks about all this. I try to bring this stuff up in meetings and I get the o'l "It's working" argument. Sounds like I have a real nice shit sandwich to deal with.
"So did you try and obfuscate stuff?" Yes; because of the public Ip's, I was uneasy to post that information on a public forum. And I do not know why they used all these public IP's. They bought all these IP's and set up their 'LAN' using public IP's. Hell, even my workstation has its own public IP. Its important to note that my company is an ISP so they are in control of all these IP's. Still, it baffles me why they used all these public IP's to setup their infrastructure.
"Who set this nonsense up??" The guy who set it up got promoted! My upper management is not very versed in technology. I had to explain to my director what the linux mascot TUX was. They saw a penguin on my screen and they were like: "whats that?"
No these servers do not need to be accessed remotely.
Well the good news is that I guess there are cleaning this up so we will see. Would using pfSense or some other device help in this situation? As of right now, I have to manage all these backup servers and make sure that they are all multi-homed to all these networks. It would make sense to me to have pfSense multi-homed and route the traffic to these backup servers?
And yes, no network topology map exists. I am trying to get one put together, but with how everything is setup, makes it very difficult.
Thanks Again!
-
"Yes; because of the public Ip's,"
So how exactly did you change stuff - for example the one with gateway outside of its network? A simple way would of been to just replace the first 2 octets with say letters.. And stating that they are public…
Why would you change macs???
Did you just delete some stuff? Why do some networks have gateways and others do not? Do you really have public IPs on interfaces with no gateway?? So do they actually own all the public space they are using? Do you have different public networks from multiple carriers? Or is that just your obfuscation causing more confusion?
-
-
OK, Changed all assigned IP's to host-names to avoid confusion.
Yes my company owns ALL these public IP addresses and they are their own ISP. Don't know why they assigned all these public IP addresses. Like I said, my workstation has a public IP address. From what I can make of it, they treat their public IP's like private IP's?
I really don't get it. Suppose CommCast gave my 100 public IP's for my personal use that we routable to my home. Would I assign ALL my devices their own public IP (eg: media server, laptop, tablet, etc). Whats the benefit?
Also, I did not delete any information. I just changed the IP's and MAC's. How would changing the MAC address change how it is presented other that the identity of the device?
-
"Whats the benefit?"
No nat ;) this is how it will be once ipv6 is mainstream.. There is nothing really wrong with using your public on your network, if you actually OWN them.. most of the time companies don't own enough space.. My current company owns a /16, none of which is used internally since it would not be enough. Only public facing use it.
Your server had private and public on it?? Do they really have enough space to waste it on stuff that has no need.. I highly doubt your workstation for example needs a public.. You sure they are not just stealing public space and using it internally. My company does that as well - I have bitched about it since I have worked for them, it was done way before I ever got there - but they use for example the 6. space - freaking owned by the dod.. Stupid!!!
As to changing to names… Dude that is not any better than your stupid vlan numbers.. What is so hard in changing to letter a couple of the octets..
Lets say you had
1.2.3.4 /24
4.5.6.7 /23a.b.3.4/24
c.d.5.7/24Always replacing number with same letter.. in the first two octets... This allows us to know if same network, same space, etc. etc.. without really knowing actual public..
But to be honest its past that point - its a complete and utter cluster of the highest degree.. There is nothing to do with it other than start from scratch as dok already mentioned.. There is no slight tweaks that would fix that mess... It needs to be completely redesigned.
You should have a core, you can either route everything back to core or route downstream as well traffic that does not need to go all the way back to core.. Typical core, distribution and access layer setup is very common. With redundant links. isolation of internal and external stuff, etc.. There are multiple ways to setup a network - what you have is just a utter mess.. I would not call it a network.. There is one thing having multi homed server for example.. A storage network, a backup network, a production network and even maybe a admin network.. See attached as a typical sort of example of network layout.
But those would normally be physical nics because you need bandwidth.. For example you want your backups to not hit your production network, when the server accesses its storage because that is where all the vms it runs are for example that wold normally be fiber switches vs your copper to your production, etc..
There are lots of ways to skin a cat.. What it seems you have is a someone torturing the cat... Doing a blood eagle on the poor thing viking style...
-
blood eagle viking style
I'm afraid to put that into google. :/