On Saturday 30 December 2006 06:48, K.R. (Randy) Lewis wrote: > OK, the subject says a lot... but, I have been fooling around with > this special setup for a few weeks and I am running > out of hair (to pull out). > > I am trying to run four (4) simultaneous PPPoE sesssions > that each get a fixed Public IP - and NAT translated each > to a distinct Inside NIC port. This will allow me to > isolate each inside Network (via NAT) to a unique > Public IP. > ------------------ (snip) > Each of the pppoe entries in my /etc/ppp/ppp.conf file have > unique usernames and are associated with unique (FixedIP) address > that have been assigned. I can cause each pppoe instance to > authenticate and give me an IP (with Gateway & DNS assigned > as expected) to each tun(n) device - starting > with tun0...through tun3. Again, as expected. > > -------- Here is almost exactly what I have in the ppp.conf > (Obviously I have modified the username/password & such.) > > pppoe0: > set device "!/usr/sbin/pppoe -n Any -i xl0" > disable acfcomp protocomp > deny acfcomp > set mtu max 1492 > set speed sync > enable lqr > set lqrperiod 5 > set cd 5 > set dial > set login > set timeout 0 > set authname [EMAIL PROTECTED] > set authkey XXXXXXXXXXXX > add! default HISADDR > enable dns > enable mssfixup > > pppoe1: > set device "!/usr/sbin/pppoe -n Any -i xl0" > disable acfcomp protocomp > deny acfcomp > set mtu max 1492 > set speed sync > enable lqr > set lqrperiod 5 > set cd 5 > set dial > set login > set timeout 0 > set authname [EMAIL PROTECTED] > set authkey XXXXXXXXXXXX > # add! default HISADDR > enable dns > enable mssfixup > > pppoe2: > . same as above, but different username > . to get a different public (fixed) IP > . > ppp0e3: > . as previous, but different username > . to get a different public (fixed) IP > . > > ------------------------- end of ppp.conf example > > The above ppp.conf entries are activated from /etc/rc.local > (at the beginning) with this kind of entry (below) > for each instance: > ----------------------- > > echo -n ' PPPoE0 - ' > ppp -ddial pppoe0 > sleep 20 > echo > . > . > . > # ...until all four (4) have completed. > # (This works, of course) > --------------- >
OK, this will not solve your problem but one thing you need to watch out for is how ppp(8) deals with assigning tunnel devices tun(4) to a bundle. Though you may be getting things in expected order on a fresh boot, it may not always be the case since you are not explicitly telling ppp to use a particular tun(4) device on each particular bundle. Since you're leaving ppp to it's own discretion to chose the tunX device, it may get it "wrong" -The result of such a mixup would mean your pf rules for a particular tun interface would not be correct. The ppp(8) man page tells you how to fix a particular tun device to a particular bundle: The -unit flag tells ppp to only attempt to open /dev/tunN. Normally, ppp will start with a value of 0 for N, and keep trying to open a tunnel device by incrementing the value of N by one each time until it succeeds. If it fails three times in a row because the device file is missing, it gives up. > What I can't grok is just how to cleanly and correctly > convince 'pf' to NAT each of these tun(n) connections > through to their companion (inside Net) NICs. These > are on a 4-Port DFE-570 card, working fine...with each > port ifconfig'd to have a unique NAT addr range. E.g., > Port0(dc0) gets 192.168.0.1/24 > Port1(dc1) gets 192.168.1.1/24 > Port2(dc2) gets 192.168.2.1/24 > and > Port3(dc3) gets 192.168.3.1/24 > as desired NAT ranges on the Inside. > > I need to be able to have all four (4) of these NICs > *translating and routing* to/from the public IP's that > are assigned to each tun(n) resulting from the pppoe(n) > sessions. > > I can get any one of them to work, transferring data fine > (I'm using it right now), but the other three just don't > offer a route to / or through the Public IP that is > assigned to subsequent tun(n)'s ... via pppoe. I believe the problem you are really fighting is the issue of the system "default route" -There is only one default route for the system and you're telling ppp to set the default route on *only* the first interface with: > add! default HISADDR The similar entries for the other bundles in your ppp.conf are commented out. You have one, and only one, default route on your system and you currently have it tied to your first ppp bundle (pppoe0). Without the first bundle (pppoe0) active, you have no default route and cannot pass traffic but with the first bundle active, everything will need to pass through it. If I have understood you correctly, what you want to do is basically equivalent to having multiple default routes, with one default route for each of your tun interfaces. Unfortunately, having multiple default routes is unsupported in every operating system I know of save MS-Windows and ms-windows quite regularly gets confused making a brutal mess out of any such attempt. In short, it can not work the way you want. Though you did a great job of explaining what you want to do, you never bothered to mention *why* you want to do it that way? Other than you "want" to do it that way, I'm curious what you really gain from this? > This will allow me to isolate each inside Network (via NAT) to a > unique Public IP. You already have "isolation" by having the private networks. I can not see how you really gain anything at all from your supposed "isolation" of private lans onto separate public IP addresses when you can just as easily do any required filtering and/or logging on the internal (private) interfaces while using only one tunnel? If you are somehow picking up a bunch of noncontiguous IP addresses from your provider, then you're really looking at a real mess. Though you might be able to force your way around the routing problems with additional routes and aliases, your outbound traffic would all be forced into the single tunnel which connects to the default route. This begs the question of why you're using multiple tunnels in the first place? A single tunnel should be more than enough if you have proper routing set up with your provider. Normally, when a service provider assigns a block of IP addresses to a client, you can usually ask them to set up routing on their end for your subnet. Basically it means that all packets destined for any of the IP's in your assigned subnet are sent to the single IP address where your router lives. This makes you responsible for all further routing past the gateway address. You would run a single ppp connection and then alias your additional IP addresses onto your tun0 interface. The "default route" on your system would point to the gateway address of your provider through the gateway address of your public subnet. In other words, the typical "!add default HISADDR" you have in your ppp.conf would work properly. You would also have a route on your system for the rest your public subnet which points to your public gateway IP. You could still do the "isolation" you mentioned by using the "$ext_if:0" "ext_if:1" and so on syntax in pf to access the different aliases. For example, assuming your provider has their gateway at 12.12.12.1 and they have given you the 14.14.14.0/29 subnet, this gives you the eight IP's 14.14.14.0 through 14.14.14.7 to play with but 14.14.14.0 is reserved as your network and 14.14.14.7 is reserved for broadcast traffic, so you only get six usable IP's. 12.12.12.1 -the gateway on your providers network 14.14.14.0 -network 14.14.14.1 -usually the gateway for your subnet 14.14.14.2 -one of your public IP addresses 14.14.14.3 -one of your public IP addresses ... 14.14.14.6 -one of your public IP addresses 14.14.14.7 -broadcast Your provider has their equipment set up to route anything destined for the 14.14.14.0/29 subnet to the 14.14.14.1 address. Your tun0 device gets the 14.14.14.1 IP address and ppp will set up your default route to your provider. Then you alias all your addtional IP addresses to the tun0 interface so incoming packets for the additional IP's are not ignored. You may need to add an additional route for your subnet so the outbound packets from your additional IP's have a way to leave. Destination Gateway Interface default 12.12.12.1 tun0 12.12.12.1 14.14.14.1 tun0 14.14.14.0/29 14.14.14.1 tun0 Bingo, you now have a router for your whole public subnet. Though there are plenty of good reasons to do things this way, such as you're hosting servers in an internal DMZ and redirecting traffic to them through a routing firewall, I can not see how the good reasons apply to your situation, namely, the need for providing simple connectivity of your multiple private lans? Since you are lucky enough to have four separate connections with fixed IP's from your provider, the smartest solution is completely different that what you are trying to do. The best answer would be to use four separate systems and then CARP them all together. The result is you now have static load balancing across the four machines as well as automatic fail-over in case one of your boxes dies. As unintuitive as it might sound, you really are much better off going into the basement and rummaging around to find a few old 486 systems that still work. Kind Regards, JCR
