Access VLANs across VPN

[DCTI]

I have a Windows XP machine that hosts an application that reads web blogs and does statistical analysis on the gathered data. We use AT&T DSL service so that we can rotate the dynamic IP address on the modem to get another unique IP address, in affect increasing the " unique IP" hits on the blog web server. The application works great when I plug a modem directly into the XP machine. Now I need to use a modem located at a remote data center. By using remote modems, we can use the pool of IPs from other geographic regions and keep our application server running locally. Currently, we ship an XP box with a modem to another geographic region, but now we want to keep the application running locally. The modems at the other end are used in their FACTORY DEFAULT state and the IP address to access the modem for management is always 192.168.0.1. Both sites use Fortigate 80C firewalls. Does anybody have any idea how I can connect to the modems across an IPSEC tunnel or some other Fortigate-to-Fortigate technology?

[rwpatterson]

First off, how does the Boston 80C differentiate between the three if they all have the same IP address? That' s the way the remote FGT is going to have to get to them as well. Your statement IP address 192.168.1.1 isn' t the same as what' s in the picture, by the way...

[DCTI]

Precisely why I am posting in this forum. My client has a competitor doing this right now with Cisco 1800 and Cisco Catalyst 2900. I am told that they use " port trunking" to extend the VLANs from one site to another. They have 4 modems, each plugged into a port on the Catalyst switch. then one single port connects to the 1800 and " trunks" the connections back to the mother ship. If I could extend the broadcast network to the remote modems, I would be able to assign the network to a NIC on the XP machine. I was thinking in my head that if I created virtual domains on the fortigate in Boston for each modem I could somehow forward that back to Seattle...but frankly I don' t know yet how I' m going to get this done. The key is that I have to literally create a LAN between the modem and the XP machine' s unique interface in order for this application to work. Best, Dave.

[emnoc]

1st off a vlan is a layer2 concept. You can' t extend a vlan in that way of a layer3. Or at least in the firewall. 802.1q tagging should not be of any concern, unless your plumbing a 2nd interface in the XP server and you want to route that over to the remote site. You diagram is clean , but how your explaining what your trying to accomplish not clear nor make any sense. 2nd what you or what we are think you need is a simple site2site VPN from remote@boston to hub seattle. Right ? 3rd, I would highly advise NOT to use a 192.168.0.0/24 in any network design. You will most likely run into issues nor or later, and more so if you interface into any other external networks. Get off it now, and change it to let' s say 192.168.223.0/24 for example. 4th, what the heck is a modem ? We have no clue as to what the purpose of that device, is a modem really a modem ( modulate or de-modulate ) or are you really trying to SNAT ( source NAT ) from the remote@boston to the hub@seattle?

[DCTI]

802.1q tagging should not be of any concern, unless your plumbing a 2nd interface in the XP server and you want to route that over to the remote site. You diagram is clean , but how your explaining what your trying to accomplish not clear nor make any sense.

The XP server will have two network interfaces, but I do not want to confuse the scope in this thread. One interface will be dedicated to connecting to the DSL modem.

2nd what you or what we are think you need is a simple site2site VPN from remote@boston to hub seattle. Right ?

There is already a site-to-site IPSEC policy-based tunnel from Seattle to Boston. There are other resources on both end of the tunnel doing other work that require the IPSEC tunnel, but again, their scope will only make this more confusing.

3rd, I would highly advise NOT to use a 192.168.0.0/24 in any network design. You will most likely run into issues nor or later, and more so if you interface into any other external networks. Get off it now, and change it to let' s say 192.168.223.0/24 for example.

I totally agree with you on this. However, there is a design requirement that after a modem is factory reset, we have to be able to access them from remote using the default IP of 192.186.0.1. Due to the inherent instability of DSL technology, we have to sometimes reset the modems to factory default state in order to restore operation to the line. We have to utilize " remote hands" at the data center in Boston as we have no actual staff there.

4th, what the heck is a modem ? We have no clue as to what the purpose of that device, is a modem really a modem ( modulate or de-modulate ) or are you really trying to SNAT ( source NAT ) from the remote@boston to the hub@seattle?

The DSL modem interfaces the regular POTS line we get from AT&T to Ethernet. Specifically, we are using PPPoE (Point To Point Protocol over Ethernet) to connect to the Internet which is why I' m trying to figure out how to extend the VLANs from Boston back to Seattle. PPPoE is also a layer2 technology. We are not " NAT" ing at all in this scenario. The PPPoE connection from the modem' s Ethernet interface provides a live public IP address to the network interface on the XP server. If the XP server and the modem were local, we could use a simple straight-through Ethernet cable directly into the NIC on the XP server and the Ethernet interface on the DSL modem. Then plug in the POTS line from AT&T into the " DSL" or " WAN" port of the modem. PPPoE is negotiated and the XP box gets a public routable, dynamic IP address. Ultimate, our goal is to duplicate this process, but the modem and the XP server are remote from each other.

[emnoc]

Even more confused now seeing the newly update document and the same subnet, but now into 2 unique vlans. If I' m understanding your situation, your using PPPoE at the remote to effectively , change the SRC of the address seen at the server thing that your connecting to in the internet. Since the PPPoE is handled at the remote site, your XP machine(s) will be need locally on the lan where your DSL_modems sits at. Repeat, your NOT going to transport Layer2 over a L3 ipsec-gateway. What you might need, is some type of l2tpv3 pseudowire wire connectivity. That would then allow for the XP server at the hub, manipulate the DSL at the remote. That would be your layer2 topology, but once again, layer2 does not traffic over a L3 topology like that of a IPSEC VPN shown in your diagram. Qs: why don' t you do one of the 2; 1: move the modem/dsl-service to seattle ( very simple :) ) or 2: move the XP servers to Boston where the dsl service originate from ( once again very simple :) ) Why does the DSL_MODEM need termination at boston? Both of these would be be way smarter and simply to design and trouble-shoot. You could even virtualize the XP servers, install them in van 1 2 3 ( using your example ) and manipulate the PPPoE in whatever shape of fashion. The other option, would be to place the DSLmodems in vlan 1,2,3 , but now give them unique address likes that of 192.168.1.1 192.168.2.1 192.168.3.1 and maybe just maybe, a NAT pool created that allows for the SRC ( xp-server ) to be routed thru the NAT pool in a round-robbin like fashion. i.e XP_SRV 192.168.222.50 >>>> " request #1 websrcv over the VPN" >>> thru DSLMODEM1 XP_SRV 192.168.222.50 >>>> " request #2 websrcv over the VPN" >>> thru DSLMODEM2 XP_SRV 192.168.222.50 >>>> " request #3 websrcv over the VPN" >>> thru DSLMODEM3 Not pretty but that would be the only thing I could see that remotely works. Does DSL_MODEM perform NAT? Fortigate supports nat pools, and this might be a option, but I have no experience in that area, and I would suggest you lab it up. It might be something simple like a VIP on Fortigate80 @ remote and then the pool. Do some research and see if you can lab it up.

[DCTI]

Thanks all for your posts and replies. Since we need to extend the broadcast network across the WAN, it turns out that what we want is called Ethernet over IP (EoI) We can VLAN tag each connection and direct any random VLAN to the XP server and access the DSL modems via the same 192.168.0.1. This device does what we want: http://routerboard.com/RB2011L-IN I wish the Fortigate could do it, but... Best, Dave.

[izatt82]

So you are extending VLANS? There has to be another way right or am i missing something? Feels much more like a routing and NAT issue than a VLAN issue IMO.

[DCTI]

This non-negotiable requirement forces the use of EoI: The DSL modems must be accessible to the XP servers via their factory default IP of 192.168.0.1 We send anywhere from 4 to 10 DSL modems to remote sites so we can use the GEO IP pools of those respective locations. Currently, we are sending a PowerEdge Server running XenServer, a layer2 switch and modems to these remote sites. Then we control the Virtualized XP server from remote. We want to take the PowerEdge server out of the remote stack and send only a network device and modems to the remote locations and keep the XP servers centralized in Seattle. Using EoI solves this problem. Extend the LAN.

[emnoc]

fwiw a l2tpv3 cisco router would do exactly what you want. I.e a smaller 18XX series. if you plumb a ethernet xconnect, that port on seattle could be present at layer2 on the hub side. You will need 2 each , and I think if you where creative maybe the opensource networking cough cough Vyatta or Pfsense, might have a package or does this. I remember when I was following the vyatta crowd, their was talks of MPLS or MPLS-like features being built into the vyatta community/non-community releases using one of the xl2ltp daemons. I don' t know how with out drawing up, but with l2tp you could maybe get away with the same address present in the same vlan with some hacking around.