Yeah the major players are not going to accept mail from a IP without a valid PTR (rDNS).  Need to get with your ISP to rush that along.

One  thing I could think of to do to get your mail delivered until that is valid, is use a smarthost to deliver your mail.  Once the PTR is up and working you can switch back to sending mail directly.

So is your IP returning "rDNS containing in-addr.arpa are not acceptable" or nothing at all?  If they don't have any ptr's in place it might take them a bit longer, then just updating their already existing records.

If you don't have smarthost you can use, one thing you could do that would be very quick is fire up a VPS somewhere that the host allows you to update your own PTR.  For example I have a $15 a year VPS running on http://buyvm.net/ for play and testing and I pointed a simple no-ip.info domain to its IP, and right from the control panel of the vps I could update the PTR for this IP and it was available in minutes.

@ubuntu:~$ dig snipped.no-ip.info +short
209.xx.xx.192
@ubuntu:~$ dig -x 209.xx.xx.192 +short
snipped.no-ip.info.
@ubuntu:~$

Now as long as that IP is not on any blacklist you should be able to use it as a smarthost until your true connections rDNS is up and working.  I snipped out the details of the IP and hostname for privacy concerns.

That site I listed had my vps up and running in couple of minutes once I placed my order.  So I would think this is something you could have running in less than 30 minutes if you wanted to go that route.

It's not really clear what you're asking. Looks like you're in Brazil (or at least your IP is), you would probably be better off asking in Portuguese on our board here:
http://forum.pfsense.org/index.php/board,12.0.html

I was JUST about to remove this, when I thought … perhaps others might have the same problem.

The problem is VERY SIMPLE and this is the SECOND TIME I had to learn it.  :o

When you have multiple IP addresses on a WAN, you must setup Virtual IP addresses in order to use them. Otherwise, pfSense is only aware of the Assigned IP address on the WAN port.

Thanks for your patience with me everyone.

If the gateway on the firewall rules matching traffic from those workstations is set to only the VPN gateway and not to the WAN gateway, default, or a failover group, then it would do what you want.

If you don't have a gateway entry for the VPN, assign the VPN interface and enable it with an IP type of 'none'.

@Metu69salemi:

Is that rule top-of-the-list or is there any other rule which may "catch" traffic before this intended rule?

It's top of the list.

Are you using a 2.1 version?  I thought I was in the 2.1 section, but didn't see your version posted - my bad.  If your not using 2.1 then your in the right section.

As to your speeds, and ping times - I HATE YOU BOTH!! ;)  Im on 16/2 connection, that burst to 25/4 for first few seconds of the connection.  Ping to gateway is around 9-13 which isn't all that bad..  But when the speedtest servers can not keep up with your speeds, I feel real bad for you ;) hehehe

Oh wait you were in the 2.1 section

2.1 Snapshot Feedback and Problems» NAT reflection is not working.

So you double posted??  not good idea ;)

Jimp,

In order to pass L2TP over IPSec successfully, do I require rules in both Port Forwarding as well as Outbound, or just one of the two?

Ok so your using active.  Which means the client sends some random Port and server will connect to your client on that port from Port 20.

The issue is, that on site B the servers source port is 20.  But after it goes through NAT that port could be random.  Which is why you need to setup a static port nat.  In a normal nat setup you run into this – these are source ports going to say port 1028 on server from client

privateip:20 --->public:2028 (NAT router) publicIP:randomPORT ---> public:2028

Now to be honest your ftp helper on side A should allow for this and send the traffic in to your client.  No matter what the source port is.

All you really should have to do is setup site B to forward 21 to your server - you could lock this down so only site A IP is allowed.

When your server comes back to site A -- your ftp helper should allow the connection back in.  I don't have any problems using active pfsense from behind a nat.  Now if you lock down B to only allow specific ports outbound you might have issues?  What are your lan rules on site B?  Do you allow all outbound ports?  Even if you do not, just allow all outbound ports to site A IP from source of your ftp server private IP on your lan rules and you should be good.

What version of pfsense are you using btw.  I know I have no problems with active connections to ftp server from my clients - I am using 2.1 version of pfsense.  Let me make a test connection to show you.

edit:  So here is active connection to server on the public internet from client behind nat

Status: Resolving address of snipped.net
Status: Connecting to 173.xx.xx.xx:21...
Status: Connection established, waiting for welcome message...
Response: 220 snipped FTP Server
Command: USER johnpoz
Response: 331 Password required for johnpoz
Command: PASS **********
Response: 230 User johnpoz logged in
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Features:
Response: MDTM
snipped for brevity
Response: REST STREAM
Response: SIZE
Response: 211 End
Command: OPTS UTF8 ON
Response: 200 UTF8 set to on
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Type set to I
Command: PORT 192,168,1,100,98,136
Response: 200 PORT command successful
Command: MLSD
Response: 150 Opening ASCII mode data connection for MLSD
Response: 226 Transfer complete
Status: Directory listing successful

So you see there where client sent its Private IP of 192.168.1.100 on port (256x98+136 = 25224)

And pfsense helper changed that IP to my public one, and allowed the connection back into my client.  Unless your blocking outbound connections on your side B.  You should have no issues.  And only rule you should need is forward 21 on side B, and allow the ports outbound on your Side A

So I just looked in my states after doing a few refreshes, so the PORT command changes every time you make a data connection.

192.168.1.100:25238 <- 24.13.xx.xx:25238 <- 173.xx.xx.xx:20

Notice how the public port is same as private port - that is doing a static nat.  That is not always the case in a napt nat setup you could have something like this in the state

192.168.1.100:2283 <- 24.13.xx.xx:25238 <- 173.xx.xx.xx:20

Thanks.

Looking like that is indeed how it is behaving.

Guess I should have just tried it first.

Have you tried enabling the loop back configuation, to allow using External Ips?

You want to reverse the order of those NAT entries. NAT works on a first-match basis so your email server is hitting that first LAN NAT rule and sending the traffic out your default NAT. If you list that email server NAT rule first, your email server will use it instead (and all other LAN traffic will use your LAN NAT).

There was two different public ip-addresses and problem was, that when you entered public-ip#2 machine behind public-ip#1 answers

"Transparent" proxying it means transparent to the client - meaning, they don't need to change their settings.

It does not mean it is transparent to the network.

Anything that proxies is going to change the source address to that of the proxy (without some hacked-up Linux-proprietary tproxy mojo going on)

That's just how proxies work by their nature. The proxy is the one requesting the pages from the servers, not the client.

If you box be it real hardware or a VM is getting IP from your pfsense dhcp server and you want it to always get the same IP then just set a reservation.  But these would be outside your standard dhcp scope.

So for example your dhcp range is 10.0.1.14 to 10.0.1.34 then you could make your reservation or static mapping <.14 or >.34

@Metu69salemi:

That is something what i haven't done yet with pfsense(public ip behind pfsense). But i think, that manual outbound nat is something, which can help you at least with missing rule.

alright so im going to try it with 1:1 nat since its simple and easy. I want to 1:1 Nat but in order to do that the dhcp from pfsense needs to automatically assign the ip from the DHCP available ip list to the vps. In my case the vps are being created via the solusvm interface and it doesn't give you the option to obtain the ip via dhcp like a normal server would.

Can you show a screenshot of your new AoN ruleset?

Looks like it may have been hardware related on the PC side.  Tested a different machine and it seems to be working properly now.

And did you enable NAT reflection?  If you coming from the inside that is what your doing.  Why not resolve the fqdn to your local IP in the first place?  Vs hitting pfsense just to get sent back in?

That would be for connections terminating at the firewall/router - these are simply passing through.

You might need to worry about such things on your server, but not the firewall.

I think that's what happens when you change from TCP or UDP to GRE on a port forward, it doesn't clear the fields. If you start from scratch and pick GRE it doesn't do that. 2.1 completely fixes.