> -----Original Message-----
> From: Michael Tremer [mailto:michael.tremer(a)ipfire.org]
> Sent: Tuesday, May 19, 2015 11:48
> To: Alexander Weber
> Cc: development(a)lists.ipfire.org
> Subject: Re: static via dhcp/pppoe + additonal static IPs (UK BT infinity, AT/CH
> UPC Business, CH Init7)
> 
> Hi,
> 
> On Mon, 2015-05-18 at 12:56 +0000, Alexander Weber wrote:
> > Sorry, noted.
> 
> no worries.
> 
> > Challenge: add static IPs (/32) or a routed subnet to a non STATIC RED
> connection eg. DHCP, PPPoE, Dial-Up etc.
> >
> > Obvious issue(s) w/ solution:
> > - Error message in aliases.cgi -> just cosmetic and a quick rewrite to
> > "|| DHCP" or whatever we got workging later
> > - /etc/rcd/init.d/networking/red starts setaliases (c-program) only if
> > STATIC -> again a quick rewrite to run the script whith other settings
> > - /usr/local/bin/setaliases gets variables from the
> /var/ipfire/network/aliases without issues, but /var/ipfire/network/settings
> does not contain them when connection is not static, eg. red gateway or red
> subnetmask.
> > In this case I assume the vars need to come from ipfire/dhcpc and the
> ethernet setting?
> 
> Please commit these changes to a git repository so that we can keep track of
> them individually.
> 
> As far as I understand, you already changed the aliases.cgi file. So this is
> probably done?
> 
> I sent you a changed version of the setaliases binary. Do these changes
> work?

[APW]  Will commit when I have a working config. Yes, aliases.cgi and /etc/rcd/init.d/networking/red, however these changes do not make sense when the rest is not working.

[APW] The file you sent me worked, however, as these variables need to come from other files when not STATIC, so it does not collect the right information yet. Therefore I wanted to find the working confg first before bothering you again for a recompile.
> 
> The last point is a bit tricky. The setting file is read to find out about the
> netmask and broadcast address. The broadcast address is not actually
> needed if we replace that ifconfig command by the ip command (even
> ifconfig should not require it).
> 

 [APW] indeed, ifconfig does not need a subnet/gw but will then try to be clever and set it on his own mostly to xy.255.255.255 which is obviously wrong. Nevertheless I gave event this config a shot but got then kind of strange routing when pinging from outside, where the last hops where: Provider - IPFire - Provider - 85.195.224.66

> The bit with the netmask is more complicated. setaliases assumes that the
> network is one network in which all the IP addresses are. That is most likely
> not the case for your DHCP setup and you usually don't get consecutive IP
> addresses when you order extra ones in a data center.
> They will give you what ever is not allocated.
> 
[APW] Exactly

> So I suppose that it should be fine if we set those up with /32 as you do
> further below. I am not aware if any disadvantages.
> 
> > Config:
> > Static via DHCP
> > IP: 212.51.153.253
> > SN: 255.255.255.0
> > GW: 212.51.153.1
> > BC: 212.51.153.255
> >
> > Static routed subnet: 85.195.224.64/29
> >
> > Real issue(s) w/o solution:
> > So I tried directly attaching each IP to make all IPs available to DNAT:
> >
> > $ ifconfig red0:0 85.195.224.64 netmask 255.255.255.255 up $ $
> > /usr/sbin/arping -c 1 -w 1 -i red0 -S 85.195.224.64 212.51.153.1 In
> > WebIFC with the corresponding DNAT and SNAT entry
> >
> > And routed:
> > $ ifconfig red0:0 85.195.224.65 netmask 255.255.255.248 up $ $
> > /usr/sbin/arping -c 1 -w 1 -i red0 -S 85.195.224.65 85.195.224.64 In
> > WebIFC, static routes: 85.195.224.64/29 gw: 85.195.224.65
> >
> > With or without any configuration changes except firewall rules the
> package leaves the origin, arrives at the correct alias, is correctly transmitted
> to the destination server. The corresponging ACK comes back from the
> destination server, leaves the firewall on RED but never arrives athe the
> origin.
> >
> > I called the provider and he sees the incoming pacakges correctly routing,
> but he cannot inspect the outgoing ones and state if they are correct or not.
> >
> > Forum:
> >
> http://forum.ipfire.org/viewtopic.php?f=51&t=12800&sid=08a461d562a2eea
> > 83d1224c2980882ab
> >
> > Any ideas hints or comments are highly appreciated.
> 
> It is a bit hard to say what is going wrong here. Do you think that the firewall
> drops the packet?

[APW] Mh, from what I see it does not, but cannot confirm as I do not have any way to intercept traffic after it left IPFire. Mh, I do, when I bring up virtualIPFire whitin my GREEN, assigning IP via DHCP. Then set a static route on my realIPFire to a /29 subnet different to my GREEN. Finally NetworkMonitor/Whireshark.

VM is booting, I'll report back later or tomorrow.

Cheers, Alex

> 
> -Michael
> 
> >
> > Thanks,
> >
> > Alex
> >
> > -----Original Message-----
> > From: Michael Tremer [mailto:michael.tremer(a)ipfire.org]
> > Sent: Wednesday, May 06, 2015 12:47
> > To: Alexander Weber
> > Cc: development(a)lists.ipfire.org
> > Subject: Re: static via dhcp/pppoe + additonal static IPs (UK BT
> > infinity, AT/CH UPC Business, CH Init7)
> >
> > Hello Alex,
> >
> > we speak English on this list.
> >
> > What I would need for a beginning is recap of what is supposed to be done
> here and what the current state of your efforts is.
> >
> > I have not been following the forum thread very closely and I am now not
> in a position to tell what is working and what is not and what problem you are
> trying to solve right now.
> >
> > Best,
> > -Michael
> >
> > On Tue, 2015-05-05 at 14:44 +0000, Alexander Weber wrote:
> > > Hi,
> > >
> > > Haette auch vermutet einfach den GW von der DHCP Adresse
> herzunehmen
> > > tut, aber wohl nein.
> > >
> > > Ich glaube das grosse Problem liegt daran, dass eine IP aus einem
> > > Subnet fix per DHCP kommt und die weiteren IPs aus einem Anderen.
> > > Vielleicht bin ich auch zu ungeduldig, siehe
> > > http://shorewall.net/shorewall_setup_guide.htm#ProxyARP
> kommender
> > > Absatz CAUTION und der Provider hats nicht geaendert – dagegen
> > > spricht aber ein traceroute (siehe Attachments).
> > >
> > > Pfsense hat es geloest, da heist es VIP, ich lad mir mal die Distro
> > > und schaue mir an wie es dort geloest ist, vielleicht bringt das ja
> > > noch eine Idee.
> > >
> > > Cheers,
> > >
> > > Alex
> > >
> > >
> > >
> __________________________________________________________
> __________
> > > __
> > > Sent: Tue May 05, 2015 12:51 pm
> > > From: MichaelTremer
> > > Recipient:NODeeJay
> > >
> > > Hi,
> > >
> > > das sind jetzt nicht gerade all zu viele Informationen...
> > >
> > > Grundsätzlich ist das egal welche Subnetzmaske du benutzt. Das
> > > Gateway ist doch sowieso klar oder? Oder ist wirklich eine Adresse
> > > aus dem Netz das Gateway für das Netz?
> > >
> > > Können wir die ganze Diskussion auch auf der Devel Mailing Liste
> > > führen? Dann sind mehr Leute dabei...
> > >
> > > NODeeJay wrote:Hey Michael,
> > >
> > > ich hab jetzt alles was mir einfiel versucht, mit SNAT/DNAT, ohne,
> > > mit dem Gateway vom der DHCP Adresse, mit einer Route zum
> gerouteten
> > > Netz etc.
> > > In allen Faellen gehen lt. tcpdump auch ACKs raus, kommen aber nie an.
> > > Arping liefert uebrigens auch immer 100% Verlust. Vielleicht bin ich
> > > mittelerweile auch Konsolenblind geworden.
> > >
> > > Config
> > > statische via DHCP
> > > IP: 212.51.153.253
> > > SN: 255.255.255.0
> > > GW: 212.51.153.1
> > > BC: 212.51.153.255
> > >
> > > fixe: 85.195.224.64/29
> > >
> > > was m.E. funktionierte sollte
> > > nicht gerouted:
> > >
> > > Code: Select all
> > >
> > > $ ifconfig red0:0 85.195.224.64 netmask 255.255.255.255 up $
> > > /usr/sbin/arping -c 1 -w 1 -i red0 -S 85.195.224.64 212.51.153.1
> > >
> > >
> > >
> > > gerouted:
> > >
> > > Code: Select all
> > >
> > > $ ifconfig red0:0 85.195.224.65 netmask 255.255.255.248 up $
> > > /usr/sbin/arping -c 1 -w 1 -i red0 -S 85.195.224.65 85.195.224.64
> > >
> > >
> > >
> > > und die Route unter den statischen mit 85.195.224.64/29 gw:
> > > 85.195.224.65 eingetragen.
> > >
> > > beim Provider ist lt Provider alles i.O.
> > >
> > > Vielleicht siehst Du noch wo das Problem sein koennte, im Prinzip
> > > ist es ja nichts anderes als auf DD-WRT
> > > http://www.dd-wrt.com/phpBB2/viewtopic. ... 639#211639.
> > >
> > > Cheers,
> > >
> > > Alex
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Development mailing list
> > > Development(a)lists.ipfire.org
> > > http://lists.ipfire.org/mailman/listinfo/development