How can I publish a Server via a public IP from the same Subnet of the WAN Interface?

[vertical]

Hi guys,

I'm new to PAN Firewalls and currently I am trying to publish a customer's SBS Server via a PAN200. The Firewall has the public IP 218.1.1.218(of course i posted a fake one ) and the server shall be accessible via 218.1.1.220.

- I've configured Accessrules allowing traffic from WAN to LAN + SBS internal IP

-  Static unidirectional NAT for LAN -> WAN source sbs internal to 218.1.1.220

- Destination NAT for WAN -> WAN destination 218.1.1.220 to SBS internal IP

I've tried to reach the server and I can't find anything recorder in traffic monitoring.

Hope someone has a idea to solve this.

Best regards

[panos]

Hi,

Try to telnet from outside to that 220 ip for the related port and see from monitor if it shows the logs and NAT works or not

[vertical]

doesn't get logged either

[panos]

can you type your security rule and Nat rule for that traffic with details

[harshanatarajan]

Are you filtering the the traffic logs with destination set to the external IP address ?

[vertical]

security rule:

source zone: WAN any any any

dest zone: LAN SBS_internal

application and service: any

NAT:

rule 1:

src zone: LAN src address SBS_internal

dst zone: WAN

static nat: 218.1.1.220

bi directional: no

rule 2:

src zone: WAN

dst zone: WAN dst address 218.1.1.220

Dest NAT: SBS_internal

all rules are on top, so nat+pat doesn't hit traffic from the server.

pinged 8.8.8.8 from the server and it was sucessfully nat'ed to the expected public IP and replies came back in. however inbound connections are not logged for this public ip

yep also filtered the logs for the specific ip or WAN as dst zone, but even without filters i didn't see the traffic

[panos · Accepted solution]

change SBS_internal to public ip address on security rule

[harshanatarajan]

Have you specified the external ip address in the security rule ? If not can you specify the pre NAT address in the destination address field.

[vertical]

thanks guys, that was indeed the problem

for those wondering why the traffic was dropped but not logged: you need to define a rule that matches a drop, the default deny rule does not log.