WuckaChucka's questions

I know this seems like a homework question, but it's actually part of a larger project (and network) and need to break it down into chunks so I'm clear with what I'm doing. I've never worked with [R/M]STP and have only setup a static LAG before, so I'm not really sure what I need here.

I have three switches all within the same broadcast domain by way of VLAN tagging, interconnected by a LAG group consisting of 2 x copper Gigabit ethernet per LAG group.

Assume these switches support LAG/LACP/*STP/802.1q VLAN tagging; trying to minimize vendor-proprietary extensions here for sake of comparison, but if there's a vendor "re-badged" open standard, or worth mention, please feel free to do so.

Goals are:

• to have redundant uplinks for switch A via B and C
• to have load balancing/increased bandwidth across both uplinks (if possible, i.e. 4 x GbE LAG group or 2 x 2 GbE LAG group "active/passive" if that makes sense)

What I'm not sure of is:

1. Here's how I think this loop works: an ARP request from Machine B1 (on Switch B) looking for 1.2.3.4, which belongs to Machine A1 (on Switch A), would arrive on Switch A from both A-to-B and A-to-C uplinks. Switch A would (I'm assuming) receive the broadcast first via the direct B-to-A LAG uplink, but would send the response back from both uplink LAG ports (i.e. LAG A-to-B is ports 1/2 and LAG A-to-C is ports 23/24), confusing Switch B greatly. Am I correct in how I'm interpreting this loop?

2. If my assertion that #1 is indeed a loop, I need *STP. From what I've read, STP is old and slow; RSTP is much quicker (may be moot point on all but the largest networks? Seems to be what the Intarweb is saying). Then there's MSTP, which confused the heck out of me: seems to allow multiple STP groups for multiple VLANs but assuming I'm dealing with just one VLAN (2), is this necessary? What if I added a second VLAN that carried across all 3 switches?

3. I'm pretty sure that M-LAG (I think that's what it's called) will allow LAGs that span across switches, but I'm not clear on if this would be a LAG that includes the 4 ethernet connections that comprise Switch A's A-to-B (2) and A-to-C (2) uplinks?

4. I've read on a forum somewhere (can't recall where) that LACP would eliminate the need for *STP because it's "dynamic" and would "know" which uplink to forward the broadcasts/unicast traffic based on load balancing algorithms, but someone chimed in later that this wasn't the case.

To boil this down, given the acronym soup of LAG/LACP/*STP and my topology, what should I be doing at a high level here?

I'm curious as to what's the standard method of telling a startup script to execute with certain parameters.

For instance with MySQL, there's my.cnf, and from what I can tell, the startup parameters are derived by configuration options specified in my.cnf (i.e. --bind-address=127.0.0.1 corresponds to bind-address option in the my.cnf file and so on).

I always assumed that every daemon/service would have a configuration file in /etc/<some_app> and that these startup options are determined with it. However, I've ran into several daemon/services that I can't find where/how it determines what parameters to startup with. /etc/init.d/<some_script> usually has several conditionals and the usual defaults, but I'm not sure where these startup options are actually determined. Couple of examples are pure-ftpd and mediatomb; can't tell from the init.d script how the parameters are defined: the former has a conf/ sub-directory with files representing startup options (these seem to be a Debian/Ubuntu specific configuration method as the apt package installs the pure-ftpd-wrapper which references these conf files). With mediatomb, there's just a config.xml file.

I guess the question could be phrased as, "if you're looking to change startup options for a typical package-installed daemon/service application on a Debian-like system, where should you look?"

I know this is possible -- and apparently fairly common with larger companies that don't/can't route private addresses for overlap reasons -- but I can't wrap my head around how to get this to work. I'm playing around with pfSense, Vyatta and a Cisco 5505 right now, hardware-wise.

So here's my setup:

WEST: Vyatta

• outside: 10.0.0.254/24
• inside: 172.16.0.1/24
• machine a: 172.16.0.200/24

EAST: Cisco 5505

• outside: 10.0.0.210/24
• inside: 192.168.10.1
• machine b (webserver): 192.168.10.2

So what we're trying to do is this: route traffic across the tunnel from machine A to machine B without using private addresses. i.e. 172.16.0.200 makes a TCP request to 10.0.0.210:80, and as far as EAST is concerned, it sees a src IP of 10.0.0.254.

On WEST, I have your typical many-to-one Source NAT to translate 172.16.0.0/24 to 10.0.0.254 and that's confirmed to be working.

Also on WEST, I have the following IPSec config:

• Local IP: 10.0.0.254
• Peer IP: 10.0.0.210
• local subnet: 10.0.0.254/32
• remote subnet: 10.0.0.210/32

I have the reversed configuration on EAST. What happens when I make a request from machine A to 10.0.0.210:80 is that the SNAT translates the private address of machine A to 10.0.0.254 and it's routed out (and discarded at the other end) without establishing the tunnel. What I'm assuming is happening is that the inside interface on WEST receives a packet from 172.16.0.200 and since this doesn't match the local subnet defined in the tunnel configuration, it's not processed by the IPSec engine and the tunnel is not established.

How do you make this work? Seems like a chicken and egg thing with the NAT and IPSec and I just can't wrap my head around how this can be done: can I say, "if a packet is received on the inside interface with a destination of 10.0.0.210, translate it to 10.0.0.254 before the IPSec engine inspects it"?

I may have a need to add (to start) 10 IPSec tunnels in a hub-spoke design, whereas communication is one-way (spokes -> hub only) for the purpose of collecting data in a central database server. Each transaction is small, perhaps 10Kb in XML data, and with each spoke initiating maybe 10-20 transactions an hour. Also I should note that I don't have control over the the spoke networks; all spokes have a static, publicly-routeable IP address; all spokes are really just a host behind a NAT firewall that needs to send data to the central database. The central database is behind a NAT firewall and for purpose of discussion, is on a 192.168.0.0/24 subnet.

My initial thought was that IPSec tunnels were overhead/overkill as I'd have to think about each spoke's network topology (which I don't control) as far as routes go not to mention the hardware required to sustain all these IPSec tunnels (especially if it scales up to hundreds).

However, I'm being "urged" to go with IPSec tunnels because they're the most "secure," but in my opinion, I feel like IPSec works great for a big trusted network or even mostly trusted LAN-to-LAN communications between branch offices, especially where you have complete control over the network topology, but not so much for a very narrow purpose and one that (I think) could be achieved with something like SSH tunnels or SFTP batch jobs (or possibly on-demand/mobile VPN?).

If I have to go with IPSec, how do I handle routes? I mean, if my central database is on a 192.168.0.0/24 subnet, and spoke A happens to have the same (or perhaps another tunnel somewhere else with that), how would I be able to resolve that? Static routes on each "sending" host might work, but what if that host needs to access that same subnet somewhere else?

If not IPSec, what would you recommend for securing transactions from peers to the central host?

Setting up Postfix and Apache/PHP on an Ubuntu server. Mail's now going out ok with the proper domain name, but the local part display name is always "www-data" as I'm assuming Postfix uses the name of the user by default.

In the php.ini file, I was able to change the sendmail_path to sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]" but the email display name still appears as www-data . I tried specifying the display name a few different ways but that was ignored and the mail still went out as www-data.

What I'd like to be able to do is by default, have any mail with missing from, return-path, etc. headers go out as "Example Support" <[email protected]>, but I'm not sure if that's possible.

I've been asked to look into placing a firewall between a webserver (Debian/Apache/PHP) in the DMZ and a backend MySQL database to achieve "isolation". Right now, iptables is running on the MySQL server and is only permitting TCP 22 and 3306 for SSH and MySQL respectively. However, this is apparently not good enough, and a hardware firewall is recommended.

Looking at Cisco's ASA 5505 for example, the max. throughput is 150Mbps, which seems like quite a step down compared to the Gigabit throughput that the Webserver and MySQL server enjoy now being on the same GbE switch.

Is this a concern? I can't really give you any numbers right now, but say your typical form-driven, data entry CRUD webapp with perhaps 100 concurrent user sessions at any time.

If this is impossible to determine without any real throughput numbers, can anyone suggest any methods of measuring? I was thinking of grabbing JMeter, simulating some load, and measuring bandwidth on a port mirror of the MySQL interface (or perhaps on the MySQL server itself) with ntop.

EDIT:

I bolded the item about the Gigabit Ethernet, which should have a theoretical throughput of 125MB/s, whereas the Cisco 5505 has a max throughput of 150Mbps (or ~18MB/s) and that's not accounting for NAT or ACL parsing etc (although I can't see NAT or ACL parsing being a big deal for a one-node network). Even still, the firewall would definitely be a potential bottleneck between the webserver and the MySQL server, seeing as a good, RAID1 setup with high-quality SAS disks and other server components should at least be able to push 50-75MB/s.

I'd like to setup a site-to-site IPSec VPN tunnel between a head office and a branch office, and for political/security reasons, with the sole purpose of being able to access a "Management" subnet at the branch office, not their main LAN.

None of the NICs on this "management" VLAN/subnet have a default gateway: these devices that need to be managed are multi-homed and "straddle" both networks, and because they require Internet access out through the LAN VLAN/subnet, the NIC that's on the LAN VLAN/subnet has a default gateway set as 10.0.0.1; the MGMT NICs do not have a default gateway.

Because there's no default gateway on those NICs, I'm assuming I'll have to setup a bridged VPN vs. a routed VPN, so that my HQ LAN machines will have a VPN IP on the MGMT network (say 10.1.1.254/24). I'm assuming these devices don't support static routes (some of them are appliances with limited network configuration).

I'm pretty sure this is how your typical Microsoft RRAS PPTP setup works when you dial in through an XP workstation's VPN client, but can this work for multiple machines on the HQ? I'm assuming each HQ machine would be SNATing behind that VPN IP of 10.1.1.254? Does Cisco ASA 5505 support this? I don't want to allow any traffic back through the tunnel to the HQ LAN either.

EDIT I'll likely setup a small broadcast domain in an isolated MGMT VLAN on the HQ side to minimize all that ARP/broadcast traffic going over the tunnel.

[HQ]

LAN: 192.168.0.0/24

GW (Cisco ASA 5505): 192.168.0.1

[Branch]

"LAN" VLAN/subnet: 10.0.0.0/24 GW (fe0 10.0.0.1/24)

"MGMT" VLAN/subnet: 10.1.1.0/24 (fe1 10.1.1.0/24)

Spam's been getting through Postini lately that's addressed to a recipient ([email protected]) in the To: field and in the headers. While this isn't that strange -- we've had spam get through before -- the fact that I can't tell how mail addressed to [email protected] is going to myself and at least one other staff member.

The headers show that it's being received by Postini's gateway and sent to our Exchange Server, but spam or not, that shouldn't effect routing at all. None of us are getting any "regular" mail that's addressed to [email protected], just these spam messages. Just to make sure I wasn't crazy I telnet'ed into the Exchange Server from another machine and sent a message to [email protected] and none of us got it.

I checked to see if there's delivery options with a forwarder on his Exchange mailbox, but there's none. I also checked to see if some distribution group was setup and there isn't.

Again, all of these checks I've done seem pointless because the rcpt to determines to what address delivery is attempted. I've turned on diagnostics logging to see if anything odd turns up but the Outlook headers shouldn't "lie", should they? Anything else I'm missing? We're running Exchange 2007 (SBS 2008).

I have a feeling the answer is policy-routing, but I'd like someone to clarify that.

Basically I'm not having any luck getting NAT to work with two WAN interfaces.

I have two WAN interfaces: fe0/1 (static, 200.200.200.2/30, gw 200.200.200.1/30) and fe0/0/0 (Dialer1).

I've setup permanent static routes for various IPs to route out through fe0/1. I believe this is working ok -- I can traceroute from the IOS shell and it's going out fe0/1. I also have NAT working for Dialer1; machines on the LAN can get out without issue. However, machines on the LAN cannot get out on fe0/1 (ping static.routed.ip.address doesn't work).

Here's what I have in my config that's relevant:

access-list 1 permit 192.168.0.0 0.0.0.255

ip nat inside source list 1 interface Dialer1 overload

I've tried adding a pool and associating it with access-list 1; I also created another access-list 15 with the same LAN ip network address, but they all just seem to "replace" the NAT scheme so that my static routes work for fe0/1 (tested from LAN with ping static.routed.ip.address), but stop working for Dialer1 (fe0/0/0).

Policy-routing the only way to go here?

EDIT

I should clarify that yes, I do need to NAT overload out both interfaces: I chose to setup static routes over policy routes because I don't really care what the source IP/mask is, but the destination: any LAN packet that matches the destination address of my static routes needs to go out the fe0/1 WAN interface.

Like I said, this works from the router at all times and does work from the LAN if I run: ip nat inside source list 1 interface FastEthernet0/1 overload but that kills outbound NAT for the Dialer1 (default route) and thus all other outbound traffic.

I'm looking at the Barracuda Web Application Firewall to sit in front of a LAMP server at a colo facility.

From what I gather in the documentation, you can set it up in bridged mode or routed mode, where routed mode is quoted as being "preferred as it's more secure".

Assuming that you have a firewall in front of the Barracuda, the design in my head looks like this:

LAMP server ---- Barracuda ------ firewall/router

LAMP: 192.168.1.2/30 GW: 192.168.1.1/30

Barracuda: LAN: 192.168.1.1/30 WAN: 10.0.0.2/30 GW: 10.0.0.1/30

Firewall: WAN: 200.200.200.200/28 LAN: 10.0.0.1/30

So basically the Barracuda is the inside DMZ firewall for the LAMP box, which does NAT (inside/outside), and routes to the outside firewall, which in turn does NAT (inside/outside). Double-NAT seems a bit sub-optimal when addressing/routing it this way, but I've seen plenty of diagrams (without IPs mind you) that describe this [server <- reverse proxy <- firewall] configuration.

Is this correct? What about a "normal" reverse proxy like nginx or Apache + mod_proxy? Is that normally bridged or routed? Not sure what's the best way to accomplish this.

Without measuring throughput (it's at the top of the list; this is just theoretical), I want to know the most standard method for trunking VLANs on multiple Gigabit (GbE) switches to a core Layer 3 GbE switch.

EDIT: Say you have three VLANs, two are on their own 24x10/100/1000 L2 managed switch; the other VLAN is on the core L3 switch doing inter-VLAN routing:

VLAN10 (10.0.0.0/24) Servers: your typical Windows DC/file server, Exchange, and an Accounting/SQL server.

VLAN20: (10.0.1.0/24) Sales: needs access to everything on VLAN10; doesn't need access to VLAN30 and vice-versa.

VLAN30: (10.0.2.0/24) Support: needs access to everything on VLAN10; doesn't need access to VLAN20 and vice-versa.

Here's how I think this should work in my head:

Switch #1: Ports 2-20 are assigned to VLAN20; all the Sales workstations and printers are connected here. Optional 10GbE combo port #1 is trunked to L3 switch's 10 GbE combo port #1.

Switch #2: Ports 2-20 are assigned to VLAN30; all the Support workstations and printers are connected here. Optional 10GbE combo port #1 is trunked to L3 switch's 10 GbE combo port #2.

Core L3 switch: Ports 2-10 are assigned to VLAN10; all three servers are connected here.

With a standard 10/100 x 24 switch, it'll usually come with one or two 1 GbE uplink ports; carrying over this logic to a 10/100/1000 x 24, the "optional" 10 GbE combo ports that most higher-end switches can get shouldn't really be an option.

Keep in mind I haven't tested anything yet, I'm primarily moving in this direction for growth (don't want to buy 10/100 switches and have to replace those within a couple of years) and security (being able to control access between VLANs with L3 routing/packet filtering ACLs).

Does this sound right? Do I really need the 10 GbE ports? It seems very non-standard and expensive, but it "feels" right when you think about 40 or 50 workstations trunking up to the L3 switch over 1 GbE standard ports. If say 20 workstations want to download a 10 GB image from the servers concurrently, wouldn't the trunk be the bottleneck? At least if the trunk was 10 GbE, you'd have 10x1GbE nodes being able to reach their theoretical max.

What about switch stacking? Some of the D-Links I've been looking at have HDMI interfaces for stacking. As far as I know, stacking two switches creates one logical switch, but is this just for management I/O or does the switches use the (assuming it's HDMI 1.3) 10.2 Gbps for carrying data back and forth?

I want to:

a) segment several departments into VLANs with the hopes of restricting access between them completely (Sales never needs to talk to Support's workstations or printers and vice-versa) or b) certain IP addresses and TCP/UDP ports across VLANS -- i.e. permitting the Sales VLAN to access the CRM Web Server in the Server VLAN on port 443 only.

Port-wise, I'll need a 48-port switch and another 24-port switch to go with the two existing 24-port Layer 2 switches (Linksys); I'm looking at going with D-Links or HP Procurves as Cisco is out of our price range.

Question #1:

From what I understand (and please correct me if I'm wrong), if the Servers (VLAN10) and Sales (VLAN20) are all on the same 48-port switch (or two stacked 24-port switches), afaik, the switch "knows" what VLANs and ports each device belongs to and will switch packets between them; I can also apply ACLs to restrict access between VLANs at this point. Is this correct?

Question #2:

Now lets say that Support (VLAN30) is on a different switch (one of the Linksys) switches.

I'm assuming I'll need to trunk (tag) switch #2's VLANs across to switch #1, so switch #1 sees switch #2's VLAN30 (and vice-versa). Once Switch #1 can "see" VLAN30, I'm assuming I can then apply ACLs as stated in Question #1. Is this correct?

Question #3:

Once Switch #1 can see all the VLANs, can I achieve the seemingly "Layer 3" ACL filtering of restricting access to Server VLAN on only certain TCP/UDP ports and IP addresses (say, only permitting 3389 to the Terminal Server, 192.168.10.4/32). I say "seemingly" because some of the Layer 2 switches mention the ability to restrict ports and IP addresses through the ACLs; I (perhaps mistakenly) thought that in order to have Layer 3 ACLs (packet filtering), I'd need to have at least one Layer 3 switch acting as a core router.

If my assumptions are incorrect, at which point do you need a Layer 3 switch for inter-VLAN routing vs. inter-VLAN switching? Is it generally only when you need that higher-level packet filtering ability between your departments?

I'm a bit confused as to why I haven't seen any references online to using Switch A's uplink port (1Gbps, 24-port 10/100) to connect to Switch B's uplink port: everything I've seen -- including documentation, forums, articles, etc. -- has Switch A's uplink port going to one of Switch B's 10/100 access ports. As I understand it, the Uplink port (besides greater speed normally) is no different than another port except that it's "internally crossed-over" so that you can use a straight cable with it.

I've also seen documentation on using the uplink port to connect a switch to a gateway router, or even a server, as it provides greater bandwidth than the access ports, but yet not sure why nobody seems to be cross-uplinking, even when there's 2 uplink ports available on some higher-end switches.

Switch in question is Linksys SRW224P (x2).

Am I missing something?