Search Results

Search found 6 results on 1 pages for 'wuckachucka'.

Page 1/1 | 1 

• YouSendIt Alternative?

  - by WuckaChucka

  Looking for a reasonably priced alternative to YouSendIt's exorbitant pricing for an embedded, unbranded (i.e. no "Uploads by SomeCompany" or at the very least, discrete, subtle co-branding) file upload solution for my client's print shop Website. To do what we want to do with YouSendIt, we're looking at a corporate account of $995 USD plus $29.99 USD monthly fee, that is only sold pro-rated, so you have to buy the entire year's worth. To me, this is just unacceptable considering the commodity pricing of storage and bandwidth nowadays. For data, we're looking at roughly 10MB per upload, with perhaps 250-1000 uploads per month, with transient data storage of no more than 30 days (and more than likely 1-2 business days) for a total of 10 GB transfer (upload) and 10 GB transfer (download, to the print shop) at the very max each month. Any ideas? Everything I've found through searching seems to be geared more towards personal file sharing and not for embedding into Websites. Thanks

  Read the article

• Cisco ASA 5505: Force NAT before IPsec?

  - by WuckaChucka

  I'm trying to route public-to-public IPs over an IPSec tunnel. However, the src IP is not "interesting" to the Cisco's IPSec engine because it doesn't appear to be getting translated to the outside IP before being evaluated by the Cisco's IPSec engine. From WEST to EAST, my public-to-public IPSec works fine: I can make a request from 192.168.0.5:any to 200.200.200.200:80 because the Vyatta does the NAT translation before the IPSec tunnel inspects the traffic, so the remote-subnet and local-subnet matches (see below). However from EAST to WEST, I see a deny in my Cisco logging buffer for Deny tcp src inside:192.168.1.5/59195 dst outside:100.100.100.100/80 which leads me to believe that the IPSec engine is not matching the encrypt_acl because the address has not been translated yet. Any ideas? WEST (Vyatta): inside: 192.168.0.0/24 inside host: 192.168.0.5/24 outside: 100.100.100.100 IPSec local-subnet: 100.100.100.100/32 IPSec remote-subnet: 200.200.200.200/32 EAST (Cisco): inside: 192.168.1.0/24 inside host: 192.168.1.5/24 (DNAT'ed on port 80 to outside) outside: 200.200.200.200 IPSec local-subnet: 200.200.200.200/32 IPSec remote-subnet: 100.100.100.100/32

  Read the article

• Public-to-Public IPSec tunnel: NAT confusion

  - by WuckaChucka

  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"?

  Read the article

• Planning trunk capacity for multiple GbE switches

  - by wuckachucka

  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. Say you have three VLANs: 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. VLAN20: (10.0.1.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?

  Read the article

• Cascading switches: uplink to uplink?

  - by wuckachucka

  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?

  Read the article

• VLAN ACLs and when to go Layer 3

  - by wuckachucka

  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?

  Read the article

1