Cannot NAT trough OPT1 interface on multiwan

[cmb]

It's not working, none of the workarounds are worth trying (short of for experimentation purposes if you want). This is the bug:
https://redmine.pfsense.org/issues/3760

[mattbunce]

Thanks cmb - That saves me spending any more time on this for now!

[eri--]

Please try a next coming snapshot it should be fixed.

[eSpezi]

Hi Ermal,

thanks a lot for addressing the issue!
Is the fix already in the Wed Oct 15 14:37:51 CDT 2014 Build?

Cheers,
Harry

[eri--]

Yeah it should be on that build or newer.

[mattbunce]

Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.

Is there anything else I should be looking at?

[phil.davis]

@mattbunce:

Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.

Is there anything else I should be looking at?

Follow the bug report also: https://redmine.pfsense.org/issues/3760
On that, cmb indicates he has done some testing and it is still not fixed.

[mattbunce]

Cheers Phil

I have already commented on the bug report too, I just didn't want to get too 'chatty' on there, because it seems the folks on there have done some pretty advanced diagnostics and I didn't want to distract from the good work they were doing :)

[eri--]

Another round of fixes.
Next snapshot should have the missing piece for fixing this.

[mattbunce]

I still can't seem to get this working on the 17th October, 11:27:45 version.

Have you had a chance to try it out ermal? Perhaps I am not configuring the Nat and Rules pages correctly?

M

[mikeisfly]

This is not working for me and I'm using 2.2-BETA (amd64) built on Fri Oct 17 20:02:23 CDT 2014 FreeBSD 10.1-RC2

I have attached my LAN, NAT (Port Forwrd), Manual Outbound NAT Rules.

I have also captured packets on both my WAN, WAN2 and LAN interfaces. On my WAN2 and LAN I can see the Syn, and the Syn Ack packets however I don't see the ack packet. Also there are some retransmissions. When I capture packets on my WAN and filter for port 32400 the capture is blank which tells me that the packet is not being sent out the default gateway. I have attached the .pcap files here in the form of a .txt file if you would like to look at them in wireshark the extension just needs to be changed back to .pcap . Hope this helps

Thanks,

P.S. Not sure why I was trying to embed these images from my onedrive folder but it didn't seem to work so I had to add attachments.

[capture on LAN.txt](/public/imported_attachments/1/capture on LAN.txt)
[capture on wan2.txt](/public/imported_attachments/1/capture on wan2.txt)

[Wolf666]

I think my problem is the same.
If someone has some spare time to read: https://forum.pfsense.org/index.php?topic=82944.0

I am running:

Version 2.2-BETA (amd64)
built on Fri Oct 17 20:02:23 CDT 2014
FreeBSD 10.1-RC2

I am available to test any solution and report back.

[mikeisfly]

It's a known bug and the developers are working on it. Until then if this is a deal breaker you can try going back to 2.1.5 until the issue is resolved. That is what I'm doing.

[stewgoin]

I'm seeing the same issues on the current snapshot – I've worked around the issue with some sourcerouting and having an upstream system on one of the WAN links handle NATting for now. That works (firewall rules forcing a gateway, then having manual NAT rules disabling NAT).

It looked like using firewall rules to force the alternate gateway would make the multiWAN NAT rules start working correctly, but I didn't test that yet. It definitely adds another layer of config management to do this, so I eagerly await having this one squished :)

[cmb]

Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

[stewgoin]

@cmb:

Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

It's just a little portion of the old home network, and thankfully the changes are easy backed out to test any fixes :)

Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.

[mattbunce]

@stewgoin:

Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.

Agreed - I'm new to pfSense, but I'm very impressed with the speed of development and the "get it right in the GUI" approach. I've been using OpenWRT for a few years and there is a real tendency to push any advanced configuration to the command line, leaving much of your intricate configuration hidden within the GUI. I think the approach pfSense takes seems much more sensible - right down for the meaningful descriptions of all parameters in within the GUI

[mattbunce]

@cmb:

Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

Hi Ermal - have yo had a chance to take a look at this yet?

M

[eri--]

Please test next coming snapshot.

[cmb]

This works for me on IPv4 now with a kernel Ermal built with the fix that'll be in the next round of snapshots. Hopefully next snapshot run will be good (first one from the 30th should have it).