The goal is to become symmetric routing:

Each interface on the server should have it’s own default gateway, which allows that interface to reply itself to incoming packets from other networks.

A normal routing table can only have one default gateway. This is quite logical since it’s the place where to send packets that do not match anything else in the rest of the table. To be able to have two default gateways, one for each interface, you need to setup policy based routing.

Policy based routing allows you to have multiple routing tables. Which table is used, depends on a set of rules.

To setup policy based routing for our example case, we will use two policy based tables. While it is possible to give a nice name to the tables (in /etc/iproute2/rt_tables), it’s not really when you only plan to have a few. Without a name, the tables are automatically created when you’re adding something to them.

Let’s start with adding a route for the network itself (link) and one for the default gateway for each interface. ens192 (192.168.0.10) will use table 1, ens224 (192.168.1.10) will use table 2.

[jensd@server ~]$ sudo ip route add 192.168.0.0/24 dev ens192 tab 1
[jensd@server ~]$ sudo ip route add 192.168.1.0/24 dev ens224 tab 2
[jensd@server ~]$ sudo ip route add default via 192.168.0.1 dev ens192 tab 1
[jensd@server ~]$ sudo ip route add default via 192.168.1.1 dev ens224 tab 2

To define when table 1 or 2 will be used, we’ll add a rule, based on the source of the packet to the policy and refresh the policy based routing:

[jensd@server ~]$ sudo ip rule add from 192.168.0.10/32 tab 1 priority 100
[jensd@server ~]$ sudo ip rule add from 192.168.1.10/32 tab 2 priority 200
[jensd@server ~]$ sudo ip route flush cache

To check if we did everything correctly, let’s list the tables and the rules:

[jensd@server ~]$ ip route show tab 1
default via 192.168.0.1 dev ens192
192.168.0.0/24 dev ens192  scope link
[jensd@server ~]$ ip route show tab 2
default via 192.168.1.1 dev ens224
192.168.1.0/24 dev ens224  scope link
[jensd@server ~]$ ip rule show
0:      from all lookup local
100:    from 192.168.0.10 lookup 1
200:    from 192.168.1.10 lookup 2
32766:  from all lookup main
32767:  from all lookup default
[jensd@server ~]$ ip route
default via 192.168.0.10 dev ens192
169.254.0.0/16 dev ens192  scope link  metric 1002
169.254.0.0/16 dev ens224  scope link  metric 1003
192.168.1.0/24 dev ens224  proto kernel  scope link  src 192.168.1.10
192.168.0.0/24 dev ens192  proto kernel  scope link  src 192.168.0.10

As you can see in the output from ip rule show, our policy based tables have a higher priority than the main table, which can be viewed with ip route. Nevertheless it’s import to still have a default route in the main table since packets leaving the machine itself can have a source IP of 0.0.0.0 and would not match any of the rules in our policy.

Make the changes permanent
Up to now, the changes would get lost after a reboot or restart of the networking. To make the changes permanent, create a route and rule file for every interface. For the above example, the contents would look like this:

[jensd@server ~]$ cat /etc/sysconfig/network-scripts/route-ens192
192.168.0.0/24 dev ens192 tab 1
default via 192.168.0.1 dev ens192 tab 1
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/route-ens224
192.168.1.0/24 dev ens224 tab 2
default via 192.168.1.1 dev ens224 tab 2
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/rule-ens192
from 192.168.0.10/32 tab 1 priority 100
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/rule-ens224
from 192.168.1.10/32 tab 2 priority 200

Now your configuration should be persistent.

Some people pointed out in the comments that, in order for the routers to be persistent, you need to first perform the following actions:

yum install NetworkManager-config-routing-rules
systemctl enable NetworkManager-dispatcher.service
systemctl start NetworkManager-dispatcher.service

While this solution is slightly more work than changing the value for rp_filter, it isn’t that hard and has a lot of advantages over the other solution.

TAKEN FROM: https://jensd.be/468/linux/two-network-cards-rp_filter

Check Virtualization Extension 

Run this command to make sure you’ve enabled virtualization in on your computer. It should be above 0

titus@debian:~$  egrep -c '(vmx|svm)' /proc/cpuinfo
12

If the output is zero then go to bios settings and enable VT-x (Virtualization Technology Extension) for Intel processor and AMD-V for AMD processor.
Install QEMU and Virtual Machine Manager

titus@debian:~$ sudo apt install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils virtinst libvirt-daemon virt-manager -y

Verify that Libvirtd service is started

titus@debian:~$ sudo systemctl status libvirtd.service


Start Default Network for Networking

VIRSH is a command to directly interact with our VMs from terminal. We use it to list networks, vm-status and various other tools when we need to make tweaks. Here is how we start the default and make it auto-start after reboot. 

titus@debian:~$ sudo virsh net-start default
Network default started
titus@debian:~$ sudo virsh net-autostart default
Network default marked as autostarted

Check status with:

titus@debian:~$ sudo virsh net-list --all
 Name      State      Autostart   Persistent
----------------------------------------------
 default   active       yes          yes

Add User to libvirt to Allow Access to VMs

titus@debian:~$ sudo adduser titus libvirt
titus@debian:~$ sudo adduser titus libvirt-qemu

Reboot and you are Finished!

Taken from: https://www.christitus.com/vm-setup-in-linux

routing traffic over wireguard with mikrotik to a specific ip address…

Routing traffic for a specific destination over the VPN is definitely much easier. After creating the VPN tunnel between two Mikrotik routers, it was a two-more step process:

/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=NAME-OF-WG-INTERFACE
/ip route
add distance=1 dst-address=ip.ip.ip.ip/32 gateway=IP-OF-WG-SERVER

Larger subnets than a single ip can be routed through the VPN, and multiple subnets can be routed too. The caveat for this simpler method is that you cannot route “all” traffic (ie. to 0.0.0.0) through the VPN, or else the client Mikrotik itself cannot route its own traffic either.

apt update
apt install apache2-utils squid -y
htpasswd -c /etc/squid/passwd kullaniciadi
wget -O /etc/squid/squid.conf http://shukko.com/squid/squ2022.conf
nano /etc/squid/squid.conf (ip adreslerini duzenle)
systemctl restart squid
systemctl enable squid

PROBLEM:

I’ve got several Ryzen Boxes with AsrockRack X470D4U and X470D4U2-2T Mainboards,

I know a lot of providers here using these exact mainboards here with their Ryzen offerrings, So maybe some help here:

My problem is after updating the latest official BMC Firmware updates,
Here https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U#Download and Here https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U2-2T#Download

Each and every mainboards BMC IPMI interface is now not responding to pings or accessible over LAN.

I can send commands using ipmitool application from linux command line.

But no matter what I do, I can’t be able to access to BMC IPMI over LAN.

Only info I can find from AsRock side is this thread from their forum:

https://forum.asrock.com/forum_posts.asp?TID=19681&KW=X470D4U&title=asrock-x470d4u-after-update-to-bmc-03-02-00-ipmi-g

But also this has got no official updates from AsRock.

Somebody mentioned https://www.asrockrack.com/support/faq.asp?id=40 this solution in that thread , but I also don’t have the luxury to reboot and flash old version of firmware as all these boxes are production boxes with several virtual servers on them.

Anybody using these mainboards have any clue about what to do to regain access to BMC IPMI Web interface?

As I said I can get response using IPMITOOL from command line. And everything seems to be working.

Please help..

SOLUTION:

Updates on this matter:

1- After tons / hours of brain thinkering and google searches I figure out that the most sensible way is to downgrade the bmc firmware to a “working” one.

2- I then needed ASPEED socflash utility v 1.2 linux version – which is very hard to get – Aspeed was providing it from their website but no more – After some google foo I found it. If anybody needs socflash utility v1.2 linux version, you are free to contact me.

3- flashed old bmc firmware with socflash linux utilty

root@r5:~/socflash/SOCFLASH# ./socflash.sh X470D4U_P2.20.00.ima X470D4U_calismayan.ima 
ASPEED SOC Flash Utility v.1.20.00 
Warning:
SoCflash utility is only for engineers to update the firmware in lab,
it is not a commercialized software product,
ASPEED has not done compatibility/reliability stress test for SoCflash.
Please do not use this utility for any mass production purpose.
Press y to continue if you are agree ....
y
Find ASPEED Device 1a03:2000 on 22:0.0 
MMIO Virtual Address: a364e000 
Relocate IO Base: f000 
Found ASPEED Device 1a03:2500 rev. 41 
Static Memory Controller Information: 
CS0 Flash Type is SPI 
CS1 Flash Type is SPI 
CS2 Flash Type is SPI 
CS3 Flash Type is NOR 
CS4 Flash Type is NOR 
Boot CS is 0 
Option Information: 
CS: 0 
Flash Type: SPI 
[Warning] Don't AC OFF or Reboot System During BMC Firmware Update!! 
[SOCFLASH] Flash ID : 1940ef 
Find Flash Chip #1: WinbondW25Q256/257 
Backup Flash Chip O.K.                 
Update Flash Chip #1 O.K.            
Update Flash Chip O.K.         
root@r5:~/socflash/SOCFLASH# 

4- After firmware downgrade:

root@r5:~/socflash/SOCFLASH# ipmitool mc info
Device ID                 : 32
Device Revision           : 1
Firmware Revision         : 2.20
IPMI Version              : 2.0
Manufacturer ID           : 49622
Manufacturer Name         : Unknown (0xC1D6)
Product ID                : 514 (0x0202)
Product Name              : Unknown (0x202)
Device Available          : yes
Provides Device SDRs      : no
Additional Device Support :
    Sensor Device
    SDR Repository Device
    SEL Device
    FRU Inventory Device
    IPMB Event Receiver
    IPMB Event Generator
    Chassis Device
Aux Firmware Rev Info     : 
    0x00
    0x00
    0x00
    0x00
root@r5:~/socflash/SOCFLASH# ipmitool lan print 1
MAC Address             : a8:a1:59:86:f3:ec
SNMP Community String   : AMI
IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl   : 0.0 seconds
Default Gateway IP      : 0.0.0.0
Default Gateway MAC     : 00:00:00:00:00:00
Backup Gateway IP       : 0.0.0.0
Backup Gateway MAC      : 00:00:00:00:00:00
802.1q VLAN ID          : Disabled
802.1q VLAN Priority    : 0
RMCP+ Cipher Suites     : 0,1,2,3,6,7,8,11,12,15,16,17
Cipher Suite Priv Max   : caaaaaaaaaaaXXX
                        :     X=Cipher Suite Unused
                        :     c=CALLBACK
                        :     u=USER
                        :     o=OPERATOR
                        :     a=ADMIN
                        :     O=OEM
Bad Password Threshold  : 0
Invalid password disable: no
Attempt Count Reset Int.: 0
User Lockout Interval   : 0
root@r5:~/socflash/SOCFLASH# 

5- Now it’s time to Enter the usual ip address / gateway of the IPMI

LAN Configuration

ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 192.168.1.211
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 192.168.1.254
ipmitool lan set 1 defgw macaddr 00:0e:0c:aa:8e:13
ipmitool lan set 1 arp respond on
ipmitool lan set 1 auth ADMIN MD5
ipmitool lan set 1 access on

User Configuration
A user will now be setup with admin rights.
ipmitool user set name 2 admin
ipmitool user set password 2
Password for user 2: 
Password for user 2: 
ipmitool channel setaccess 1 2 link=on ipmi=on callin=on privilege=4
ipmitool user enable 2
 

6- WEB INTERFACE WORKS NOW!!!

7- Time to upgrade to latest version of BMC firmware now :smile:

Thank you for all your answers!

hello, you can download it here:

https://nc.dandik.net/let/socflash.linux.v.1.20.tar.gz

full package for all OS’s is here:

https://nc.dandik.net/let/v12000.zip

cd /usr/local/directadmin/custombuild
./build set litespeed_serialno litespeedlicense#

cd /usr/local/directadmin/custombuild
./build update
./build set webserver litespeed
./build set php1_mode lsphp
./build set php2_mode lsphp
./build set php3_mode lsphp
./build set php4_mode lsphp
./build litespeed
./build php n

IF ERROR AFTER LOGIN:

Can not find handler with type: 17, name: lsphp70.
Can not find External Application: lsphp70, type: lsapi

Litespeed admin panel -> Configuration -> Server -> External App

Command Line Should Be:

php 56  : /usr/local/php56/bin/lsphp
php 70  : /usr/local/php70/bin/lsphp
php 71  : /usr/local/php71/bin/lsphp
php 72  : /usr/local/php72/bin/lsphp
php 73  : /usr/local/php73/bin/lsphp

save & Graceful Restart

UNINSTALL:

/usr/local/lsws/admin/misc/cp_switch_ws.sh apache