No, this it's not the default behaviour. Linux, Windows and FreeBSD, with default routing is replying through the same connection
only if the source belongs to a directly-connected subnet. Otherwise, the packet leaves the system through the interface which has the default gateway configured and selected.
For processes running only one instance (no setfib or similar FIB enforcement), this can be overriden with
pf() on FreeBSD, or with iproute2 and iptables on Linux. iproute2 allows next-hop selection (default route override) by a number of criteria, including the source address in the packet and the connection state.
iproute2 allows this for any process/socket, even if it's using multiple routing tables at one time. The listening process does not have to be started 'with a specific FIB'.
FreeBSD should have a FIB/connection state pairing method, iproute2 and iptables has it since many years ago.
Real-world example:
Code:
server
interfaces
eth0 - wan provider 1 (world 1, sub-world 1, preferred default route)
eth1 - wan provider 2 (world 2, sub-world 2, default route avaliable)
eth2 - wan provider 3 (world 3, sub-world 3, default route avalialbe)
...
ethN
processes
sshd
httpd
ip_addresses
172.16.0.0/24 (public addressable range 1, provider independent)
172.16.1.0/24 (public addressable range 2, provider independent)
'world' is the entire internet, 'sub-world' is the provider IP address space.
If httpd must be started with many instances (for virtual ip-based hosts), the link having the preferred default route will be overloaded if pf's route override mechanism or iproute2 is not used, if the http client belongs to world X, using the link only for the incoming packets.
If there is a routing protocol like BGP configured between this router and sub-world1/sub-world2 and sub-world3, then each client belonging to sub-world X should have it's connection replied through the arriving interface, but the ISP's IP range is usually limited.