0

I have two NICs with IPs in the same subnet.

IP1: 10.10.10.142 - Gateway: 10.10.10.129 - dev: ens192. IP2: 10.10.10.143 - Gateway: 10.10.10.129 - dev: ens256.

I want to configure static route to the IP [192.168.1.5] as following:

192.168.1.5 via 10.10.10.129 dev ens192

192.168.1.5 via 10.10.10.129 dev ens256

Now I have an issue that when [192.168.1.5] send to [10.10.10.143] I'm getting reply from [10.10.10.142].

How can I fix the static route to reply from the same IP which is receiving?

New contributor
Aboelnoor90 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
2
  • protocol is SCTP and it M3UA Application Server Oct 6 at 18:06
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    14 hours ago

1 Answer 1

0

You are correct Tom Yan, and I apologize for the incorrect information provided earlier. The rule I mentioned does not make sense in this context, and your observation about the desired behavior is accurate.

If the goal is to reply to traffic from 192.168.1.5 using the same NIC and IP address to which the original traffic was sent, you should indeed rely on connection tracking (conntrack) and marking packets appropriately.

Here's how you can achieve this using conntrack and marking packets:

  1. Delete the conflicting static route:

    If you want traffic from 192.168.1.5 to reach its destination correctly, remove the conflicting static route:

    ip route del 192.168.1.5 via 10.10.10.129 dev ens192
    
  2. Configure conntrack and packet marking:

    You can use iptables to mark packets based on their source IP address when they leave the system. For example, if traffic comes from 192.168.1.5 via ens192, mark it as follows:

    iptables -t mangle -A OUTPUT -s 192.168.1.5 -o ens192 -j MARK --set-mark 1
    

    And if traffic comes from 192.168.1.5 via ens256, mark it like this:

    iptables -t mangle -A OUTPUT -s 192.168.1.5 -o ens256 -j MARK --set-mark 2
    
  3. Create routing tables for each mark:

    Create two custom routing tables for each mark, which will determine the outgoing interface:

    echo "1 nic1" >> /etc/iproute2/rt_tables
    echo "2 nic2" >> /etc/iproute2/rt_tables
    
  4. Add routes for each routing table:

    Now, add the routes to the two custom routing tables, specifying the outgoing interface and gateway:

    For table "nic1":

    ip route add default via 10.10.10.129 dev ens192 table nic1
    

    For table "nic2":

    ip route add default via 10.10.10.129 dev ens256 table nic2
    
  5. Create ip rule entries to select the routing table based on marks:

    Create rules that select the routing table based on the mark:

    For traffic marked as "1" (ens192):

    ip rule add fwmark 1 table nic1
    

    For traffic marked as "2" (ens256):

    ip rule add fwmark 2 table nic2
    
  6. Flush the routing cache:

    ip route flush cache
    

With these changes, packets from 192.168.1.5 should be marked correctly based on their source interface, and the corresponding routing table and interface should be used for the reply. This should ensure that traffic from 192.168.1.5 receives replies from the same interface it was originally sent through.

4
  • 1
    The ip rule you give doesn't make any sense. Why would a from 192.168.1.5 rule matter to traffics that destined at 192.168.1.5? And even if you mean to 192.168.1.5, it wouldn't make much sense either. If the OP wants to always use one NIC /source IP for traffics to 192.168.1.5, why not just delete the other route? Obviously he wants to use either, depending on which the original traffic (from 192.168.1.5) were coming at, which means he need fwmark rules and the help of ct mark.
    – Tom Yan
    2 days ago
  • Yes sorry, you are correct.. I have updated my post
    – Ace
    2 days ago
  • -s 192.168.1.5 At the very least, it should be -d. Besides, I highly doubt that just matching with -o and set mark in the OUTPUT chain could get it work. Most likely you'd need to set ct mark for the connection upon receiving the original traffics and set mark for the replying traffics based on the ct mark. (In addition, I don't know if it's a good or bad idea to remove any of the route in the main table, since they might help prevent any rp filtering from kicking in.)
    – Tom Yan
    2 days ago
  • In other words, I think before a route is chosen, the output interface of the replying traffics is likely not set, and once it's set, it probably takes more than just a route choice to change it. (Or, I don't think the problem here is that we need to retain the chosen outbound interface and source IP for the replying traffics.)
    – Tom Yan
    2 days ago

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .