Did the Virtual Server take the IP of the port where it is listiening ?

Regards

Daniel

For now I have edited the local DNS server to point at the LAN ip address of the IIS server for each hosted domain and that has resolved the issue.

That's the best way to do it.  Avoid NAT Reflection if you can.

You have to think through logically how the SOAP protocol works and where your source and destination IPs are. Are you sending something from the internet into your local network? Is port 80 (this is what SOAP uses, no?) properly forwarded? Is port 80 maybe being intercepted by the management process of the pfSense firewall? Does SOAP require any funky backwards (server to client) or secondary connections (connect to 80, negotiate client-server connect to other port a la RPC) that might not be forwarded properly?

One other thing you can try is to define a custom service with the destination port TCP 80 and set the inbound (internet -> server) policy to use this new TCP 80 service and not the built-in HTTP service. Some firewalls (I'm not too familiar with pfSense, admittedly) have helper-processes that look deep into the application layer to see what's going on in the application stream, and if the SOAP protocol "looks" different than a regular HTTP request, the firewall may flag it as invalid and drop the packets. Defining a custom service will tell the firewall to only look at layer 4 (TCP/UDP Ports) and no further, ensuring that non-standard protocols using standard ports will be properly forwarded without firewall interference.

You probably don't want to get rid of NAT. If you have multiple devices behind your firewall, you will need that NAT to allow them to access the internet.

This is assuming, of course, that your provider has given you an IPv4 connection. I doubt your provider is handing out IPv6 addresses. If they were, there would be no need to NAT, as each machine behind your firewall would be getting a globally unique IPv6 address. With IPv4, you typically only get one, unless you pay handsomely for more.

If you had IPv6, you'd just have to create policies allowing connections from the internet to host xyz via port 123 and that's it. With IPv4 you have to use port forwarding, taking the 65535 available ports on your single shared public IP and forwarding them individually to particular hosts inside your network, as well as creating the above policies (if the policy isn't already implied by the port forwarding, not too familiar with pfSense, tbh).

Either way, for a bog-standard IPv4 internet connection, NAT and port forwarding are absolutely vital to make it work with multiple devices. Just forward the ports you need to the internal host you want and you'll be good to go. Alternatively, you can define one host as a DMZ, and all incoming requests will be forwarded to that host, with the exception of explicit forwardings (probably. again, not too familiar with pfSense. It's like that with other firewalls that I've worked with).

The netmask sometimes depends on the type of VIP.

https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses

@killmasta93:

#Speed up YouTube iptables -A INPUT -s 173.194.55.0/24 -j DROP iptables -A INPUT -s 206.111.0.0/16 -j DROP

pfcode does it really speed up youtube? I thought youtube had a large amount of ip tables. I tried blocking them all failed miserable. LOLZ  :-[
[/quote]

Yes. it does sometime.

Thanks.  And how do I make them an address pool?

Do I create an alias with each of the IPs in it and reference that in a single outbound NAT rule?

Or do I create a set of new outbound NAT rules, one for each VIP and reference the VIP in the Translation field?

Or something different?

Thanks,

Jeff

I didn't build that one, I was just passing it along as it was generated by another dev. The fix isn't "proper" per se, it has some issues yet. I'm not sure if getting one for i386 at this point is viable until a proper fix is committed.

In that case, yes, you must have the default of leaving static port disabled. Otherwise in that circumstance, which is atypical as most commonly used things today randomize source ports, only the first internal IP going out to the same external IP and port with the same IP translation will work. The others end up having their reply traffic sent back to the first, or dropped as not matching the state potentially.

Problem solved….

I had to make a LAN firewall rule for 10.100.0.0/16 to the outside and also outbound NAT rules for the VLANS.

Those made everything is working!

Glad it worked for you.

Thanks johnpoz and doktornotor your completely right. Its better though VPN i guess i got used to ddwrt for a while didn't want to let it go.  :P Just trying to adapt more to pfSense now  :)

Thank you again

Please don't hijack threads for unrelated problems. If you have an issue, start a new thread or if you already have, keep the discussion there.

Hi,
same problem as you.
Did you find a way?
Thanks,

This thread has already been over

so lets say I have 3 cams

cam1.dyndns.tld:8081
cam2.dyndns.tld:8082
cam3.dyndns.tld:8083

now cam1,2 and 3 all point to your public IP lets call it 4.5.6.7, and your cameras on the inside are 192.168.1.101,102 and .103

Are your cameras listening on 8081 and 8082 and 8083 or do you forward to say 80??  Really should forward to the ports your actually listening on. if cams listen on those ports your urls still work just fine be it outside or inside your network.

Also having your cameras open to the public net is not a good idea to be honest.  Why don't you just vpn in and use the private IPs directly.  This makes it simple and more secure..  Nat reflection is to be honest never a good idea ;)

@cmb:

Do you see a filter reload logged in the system log? Check /tmp/rules.debug, do you see the updated rules there? What happens if you run 'pfctl -f /tmp/rules.debug'?

Sure enough, it spit out an error of an alias url file containing rubbish on one line. This was in the locally kept version, I had already spotted the rubbish in the original source file earlier on, but as it never got as far as downloading a new copy, it never replaced the file held in the /var/db/something . Edited the local copy and it loaded normally after that.

I will see if it also saves and executes changes in the firewall, but I am sure it will, as this error block all further loading.

Thanks.

sounds more like a ssl based vpn to me..  That yes the ASA support, this has nothing to do with routing or forwarding.  And no pfsense does not support that.

Sorry to say it at this late stage, but this really illustrates the importance of taking a regular backup of your running config. Especially before making any changes.