Network issue traffic coming in one interface and leaving an other.

I understand what happens, not sure how to fix it, .. as the network is choosing to use the default gateway to leave the interface rather then answering through the interface it came from, also I would assume that since it both have different network subnets that it wouldn't do what it does.

Code:
# netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            10.35.17.1         UGS      vtnet1
10.35.15.0/24      link#1             U        vtnet0
10.35.15.10        link#1             UHS         lo0
10.35.17.0/24      link#2             U        vtnet1
10.35.17.10        link#2             UHS         lo0
127.0.0.1          link#3             UH          lo0

Code:
# tcpdump -ni vtnet0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:22:46.714033 IP 10.13.x.100.60328 > 10.35.15.10.443: Flags [S], seq 1086413690, win 64240, options [m

Code:
# tcpdump -ni vtnet1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:23:09.258229 IP 10.35.15.10.443 > 10.13.x.100.60328: Flags [S.], seq 3731273765, ack 1086413691, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4015008859 ecr 1795187956], length 0
 
I mean even the daemon isn't bound to the other interface.

Code:
# sockstat -46lp443
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
www      nginx      1115  6  tcp4   10.35.15.10:443       *:*
www      nginx      1115  7  tcp6   xx:xx:xx:dead:xx:xx:xx:xx:443 *:*
root     nginx      1114  6  tcp4   10.35.15.10:443       *:*
root     nginx      1114  7  tcp6   xx:xx:xx:dead:xx:xx:xx:xx:443 *:*
 
as the network is choosing to use the default gateway to leave the interface rather then answering through the interface it came from
Basic routing. Why would it respond on the same interface the packet came in on? Response packets get their source and destination address reversed then it'll look at the routing table to see where it should go next, 10.35.15.10 is not on any specific routing entry, so it ends up getting sent out on your "default" gateway.

It would only send the response packets back out on the vtnet0 interface if they originated from the 10.35.17.0/24 network (that's a directly connected network).

I mean even the daemon isn't bound to the other interface.
That's irrelevant. It only defines on which IP address(es) the daemon should listen on.

Notice how all the "interface" addresses have an implied route to lo0? That's because those IP addresses are actually attached to the host, not a specific interface. A network is attached to an interface (i.e. directly connected network).

You will need to add a static route for 10.35.15.0/24 to whatever IP address on 10.35.15.0/24 where the packets originated from. Or else you end up with something called "asymmetric" routing. Packets going from source to destination travel a different path than their response packets.
 
I mean I understand what happens and what it is doing, but for some reason it always worked before only starting to act up recently. Not sure what has changed since there's not been any changes to that system. The only thing what did happen was I upgraded pfsense form 2.7.2 to 2.8, ..

But that would mean that pfsense never filtered traffic before as it has a rule only allowing traffic from it's subnet. That would imply that pfsense pf never worked properly what I think is hard to believe.
 
The only thing what did happen was I upgraded pfsense form 2.7.2 to 2.8, ..
Take the issue up with the pfSense people, it's not supported here.

 
Back
Top