How to configure a static IP address with wicked?

For security reasons I have decided to put one of my servers on a separate subnet (DMZ). This poses no problems with IPv4, so the following remarks are solely related to IPv6.

My prefix is /64, so I cannot subnet. For that reason I want up set up a static route on the gateway to the server from the Internet-facing gateway. It works as expected when I do it manually:

ip route add 2001:0db8:200:4108:0:11:: dev enp3s4

Since this will not survive a reboot I try do make it permanent. I have tried to add the information to both /etc/sysconfig/network/routes

#/etc/sysconfig/network/routes
2001:0db8:200:4108:0:11::/128 ::/0 - enp3s4 -

and /etv/sysconfig/ifroute-enp3s4:

#/etv/sysconfig/ifroute-enp3s4
2001:0db8:200:4108:0:11::/128 ::/0 - enp3s4 -

but the route does not appear when I list the routes after a network restart (systemctl restart network.service):

ip -6 route list
2001:0db8:200:4000::/64 dev enp2s11  proto kernel  metric 256  pref medium
2001:0db8:200:4108::/64 dev enp3s5  proto kernel  metric 256  pref medium
fe80::253 dev enp3s4  proto kernel  metric 256  pref medium
fe80::/64 dev enp3s5  proto kernel  metric 256  pref medium
fe80::/64 dev enp3s4  proto kernel  metric 256  pref medium
fe80::/64 dev enp2s11  proto kernel  metric 256  pref medium
default via 2001:0db8:200:4000::1 dev enp2s11  metric 1024  pref medium

What am I doing wrong?

Note that enp3s4 only has a link-local address. This is deliberate.

Both my server and gateway are running openSUSE Tumbleweed updated as per today.

Well, not sure if that’s the problem, but “man ifroute” only mentions four fields, you specify five.
So try to omit the last ‘-’.

Btw, for ifroute-enp3s4 you can omit the device name as well and set ‘-’ instead. It is implicitely specified in the filename anyway.

It appears that I have misread the man page slightly. It works now. Thanks for the help.

I don’t want to split hairs, but the man pages does mention five fields in the syntax section (the fifth being ‘options’) but the examples only show four fields.

Great! :slight_smile:

I don’t want to split hairs, but the man pages does mention five fields in the syntax section (the fifth being ‘options’) but the examples only show four fields.

Ah yes, you’re right.
Maybe it doesn’t like ‘-’ as Options then?
Or the man page is wrong/outdated, might be related to the switch to Wicked…

Since you appear to be configuring an IPv6 address, I’d ask how that address was created?
It’s my understanding that if you create an IPv6 address using the prefix of your upstream (routed) Provider, the default route should be implicit without creating a special default gateway route.

This may also require re-configuring your DMZ, since your IPv6 will be on the same “network” as your public zone, so your DMZ <> Public connectivity should be “bridged” instead of “routed” which again would be consistent with the idea that all IPv6 Internet “routable”(is that even appropriate any more?) is directly accessible although filtered because in a DMZ.

TSU

As I wrote previously, my prefix is /64 (2001:0db8:200:4108::/64). The host part I created is based on the IPv4 addresses used for the hosts. For reasons not quite clear to me today I decided to move the significant bits up some octets. I did all this two or three years ago…

It’s my understanding that if you create an IPv6 address using the prefix of your upstream (routed) Provider, the default route should be implicit without creating a special default gateway route.
All my routing, also the IPv4 part, is static. I do not run radvd, meaning the odd laptop or mobile device does not get on the IPv6 part of the network without being explicitly so configured*.*
This may also require re-configuring your DMZ, since your IPv6 will be on the same “network” as your public zone, so your DMZ <> Public connectivity should be “bridged” instead of “routed” which again would be consistent with the idea that all IPv6 Internet “routable”(is that even appropriate any more?) is directly accessible although filtered because in a DMZ.
I have thought of bridging but judged the static route to be more easily implemented. The isolation of the DMZ happens in the firewall, and that work would be independent on my using bridging or a static route. I find it very easy to set up rules based on which interface packets arrive on, so filtering traffic to and from the DMZ is easy when it arrives on its own interface. The main purpose of putting the server in question (which is my web and mail server) in a DMZ is to protect the other internal hosts against attacks from the Internet-facing server, should it be ‘conquered’ by some blackhat.

Bent

You say what your prefix is, but you don’t say <how> you selected it. Did you just create it out of thin air? Was it assigned to you by someone? Or as I described, did you inspect the network and gateway router of your ISP as a reference to creating your prefix?

For that matter, I’m a bit curious that you don’t seem to have posted an “ip addr” which would have displayed any automatically generated addresses besides the ones you created. You should do so to provide more clues about your networking environment. To do this properly, you need to post your “ip addr” for both the machine in your DMZ and the firewalling Host which provides the networking connection to the Internet.

The above is what is critical for enabling automatic IPv6 routing to the Internet.
The host portion can be anything as long as it’s unique.

Until these kinds of things are commonly understood, DHCPv6 will be around for awhile Speaking of which, I guess you verified your ISP isn’t providing IPv6 DHCP today? Maybe not a few years ago but as IPv6 has become more popular and in some cases required, ISPs may be providing the service today.

TSU

I have better come out clear. The servers in question are those of AMSAT-OZ (www.amsat.dk) and they are connected to the Danish Research Network (DRN). I was told by the network administrator both what the IP address of the gateway and the prefix for my network should be. So it was done in an controlled manner - no guessing here.

For that matter, I’m a bit curious that you don’t seem to have posted an “ip addr” which would have displayed any automatically generated addresses besides the ones you created. You should do so to provide more clues about your networking environment. To do this properly, you need to post your “ip addr” for both the machine in your DMZ and the firewalling Host which provides the networking connection to the Internet.

Here they are:
The gateway: (It is enp3s4 that connects to the DMZ)

ip address list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:90:27:fc:24:fa brd ff:ff:ff:ff:ff:ff
    inet 192.168.253.1/24 brd 192.168.253.255 scope global enp3s4
       valid_lft forever preferred_lft forever
    inet6 fe80::253/128 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::290:27ff:fefc:24fa/64 scope link 
       valid_lft forever preferred_lft forever
3: enp3s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:90:27:fc:24:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.1/24 brd 192.168.254.255 scope global enp3s5
       valid_lft forever preferred_lft forever
    inet6 2001:878:200:4108:0:1::/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::290:27ff:fefc:24fb/64 scope link 
       valid_lft forever preferred_lft forever
4: enp2s11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:09:6b:45:18:b0 brd ff:ff:ff:ff:ff:ff
    inet 130.226.195.220/24 brd 130.226.195.255 scope global enp2s11
       valid_lft forever preferred_lft forever
    inet6 2001:878:200:4000::3/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::209:6bff:fe45:18b0/64 scope link 
       valid_lft forever preferred_lft forever

The DMZ server:

ip a l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:08:a1:40:1d:6a brd ff:ff:ff:ff:ff:ff
3: enp2s11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:09:6b:45:36:2f brd ff:ff:ff:ff:ff:ff
    inet 192.168.253.17/24 brd 192.168.253.255 scope global enp2s11
       valid_lft forever preferred_lft forever
    inet6 2001:878:200:4108:0:11::/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::209:6bff:fe45:362f/64 scope link 
       valid_lft forever preferred_lft forever


Until these kinds of things are commonly understood, DHCPv6 will be around for awhile Speaking of which, I guess you verified your ISP isn’t providing IPv6 DHCP today? Maybe not a few years ago but as IPv6 has become more popular and in some cases required, ISPs may be providing the service today.

TSU
Yes, I did very that DRN does not use DHCPv6, at least not in my corner of the network

Bent

OK, cool.
Just to clarify, the “DMZ Server” is the machine in your DMZ.
And, your “the gateway” is the firewalling server.

I see that your “DMZ server” has an IPv6 “scope global” address which likely is configured properly since I see a similar IPv6 “scope global” address on each of the “gateway” machine interfaces. The other addresses can be ignored now and should be irrelevant for your troubleshooting (unless they actually appear).

What is needed now is to do a “traceroute” from each of your machines to verify that both connect properly through the ISP DG IPv6 address. You might find that you’re not finding the ISP’s machine or your machine may be using IPv4 unexpectedly.

TSU

TSU

Correct

I see that your “DMZ server” has an IPv6 “scope global” address which likely is configured properly since I see a similar IPv6 “scope global” address on each of the “gateway” machine interfaces. The other addresses can be ignored now and should be irrelevant for your troubleshooting (unless they actually appear).
I am not troubleshooting - it has worked correctly ever since I got the syntax of /etc/sysconfig/network/ifroute-enp3s4 correct.

What is needed now is to do a “traceroute” from each of your machines to verify that both connect properly through the ISP DG IPv6 address. You might find that you’re not finding the ISP’s machine or your machine may be using IPv4 unexpectedly.
You are wellcome to try

traceroute6 www.amsat.dk

It will get you as far as to the gateway computer (‘gatekeeper’).

Bent