IPSEC VTI Source based routing issue

[MichaelBlly]

HI, See image below

My issue is i cant get traffic to flow back out to clients on port 25 from my mail server

On the Melbourne Router i have the following config that effects this traffic

ip nat inside source static tcp 10.121.34.1 25 interface dialer1 25
ip route 10.121.34.1 255.255.255.0 1.1.8.2

I can ping 10.121.34.1 just fine

On the pfsense firewall i have rules to allow traffic on the ipsec interface to the mail server on port 25
I have a Source route rule on the Server VLan firewall rule set to route traffic from 10.121.34.1 to 1.1.8.1

if i try connecting to the server on smtp from a machine on the internet I don't get a connection

I see the ipsec --> 10.121.34.1 rule log an accept entry

netstat on the mail server shows the connection from the internet source ip

Wireshark shows the server sending syn/ack packets back to the firewall interface

Pulling my hair out, first time ive used pfsense in this manner with ipsec tunnels. It seems pfsense is not routing the return packets back to 1.1.8.1

packet capture on pfsense

01:00:58.488295 IP 124.13.x.x.52607 > 10.121.34.1.25: tcp 0
01:00:58.488730 IP 10.121.34.1.25 > 124.13.X.X.52607: tcp 0
01:00:59.497702 IP 124.13.x.x.52607 > 10.121.34.1.25: tcp 0
01:01:01.487836 IP 10.121.34.1.25 > 124.13.X.X.52607: tcp 0
01:01:01.514040 IP 124.13.x.x.52607 > 10.121.34.1.25: tcp 0
01:01:05.530033 IP 124.13.x.x.52607 > 10.121.34.1.25: tcp 0
01:01:07.493931 IP 10.121.34.1.25 > 124.13.x.x.52607: tcp 0
01:01:11.425213 ARP, Request who-has 10.121.34.251 (00:0c:29:db:32:74) tell 10.121.34.1, length 46
01:01:11.425243 ARP, Reply 10.121.34.251 is-at 00:0c:29:db:32:74, length 28
01:01:13.535671 IP 124.13.x.x.52607 > 10.121.34.1.25: tcp 0

[A Former User]

@michaelblly said in IPSEC VTI Source based routing issue:

I have a Source route rule on the Server VLan firewall rule set to route traffic from 10.121.34.1 to 1.1.8.1

Unfortunately, it doesn't work that way. This rule will only apply if a connection is initialized from the the Mail to another host. It will not get hits for connections initialized from a client to the Mail Server on the return traffic (SYN+ACK for TCP based connections). The current (routed) IPsec Implementation in pfSense can not distinguished from which VTI the traffic originate and will Route the return traffic according to the Routing Table, whats most likely towards your default gateway.

This leaves you with two options.
You can implement a source NAT at the Cisco Router what translates the public client IP to a private IP for which your pfsense has a route towards 1.1.8.1 configured. Ye this sucks cause you cannot filter known malicious clients IPs on the Firewall, I know.

If you are running only VTI based IPsec tunnels you may want to take a look at the patch provided in this Redmine Issue. It will disable the ability to run tunnel mode based VPNs but enables the reply-to ability on the VTI Interfaces. That is what you would need to make this setup work without source NAT on the Upstream Router. I haven't tested the patch myself yet and cannot tell your if it works as indented. Use it at your own risk.

[MichaelBlly]

@artes Thanks very much for your prompt, and importantly spot on reply. I thought this may be the case and as i went to bed after i posted this query it thought that i must perform a packet capture on the wan interface and confirm 100% what you have now already done. unfortunately we have tunnel based VPN's terminating on this firewall also so that is not an option.

Now i have to figure out the NAT statement for the cisco end.

Thanks again

[MichaelBlly]

@artes
Artes, i did a test running the beta and it fixes the issue. I may look at converting all my tunnels to VTI to get around this. Actually prefer VTI anyway

[A Former User]

@michaelblly

Thank you for the feedback.