Forum Discussion
flicky2000_1616
Nimbostratus
NimbostratusWildcard Virtual Server IP Forwarding
Hi - we have an SMTP server that sits off a DMZ vlan off the F5. The D/G for the SMTP server is the real address of the F5. We want to the SMTP server to be able to make SMTP calls to any SMTP servers on the internet. Therefore we do not know the destination IP addresses. We do not want to the F5 to NAT the source IP address in anyway (the next hop after the F5 is an internet facing firewall which will NAT the source IP to a relevant RIPE address). All the literature says - just create a "IP forwarding wild card virtual server". I have and it doesn't seem to work. I can see an SMTP request from the DMZ SMTP server to another server hit the F5 on the DMZ vlan interface by doing a tcpdump. I don't see it exit the box on the other vlan interface that faces the internet firewall. So the F5 is not passing it on? What I do notice is that when I create the wildcard forwarding server the status is "blue square" (presumably because it doesn't have any pool associated with it to say it should be green and up - but you don't have pools with wildcard forwarders do you ?). So when you create the wildcard forwarder - should it be green? The config for the wildcard VS is below (and yes this is not on the default routing domain).
ltm virtual rd1-smtp-global { address-status no destination 0.0.0.0%1:any ip-forward mask any profiles { testfastl4 { } } source 0.0.0.0%1/0 translate-address disabled translate-port disabled vlans { rd1-smtp-1148 rd1-smtp-real-1140 } vlans-enabled vs-index 58
NB. the virtual address associated with the virtual server is marked as up and green cos I forced it up. But that makes no difference to the vs. I'm not sure what else I can do unless it's maybe a bug? - code version is 11.5.3. Any help greatly appreciated.
nitassEmployee
So when you create the wildcard forwarder - should it be green?
it won't because ip forwarding virtual server does not have pool. it will be green when pool is up.
I don't see it exit the box on the other vlan interface that faces the internet firewall.
have you configured default route for route domain 1 (0.0.0.0%1/0) on bigip?
flicky2000_1616nitass - I think that answers my first point. That the wildcard ip forwarding server would be blue in normal state as they can;t have pools associated to them - so the F5 box must understand this and say I will forward the traffic anyway cos it's a wildcard one. Yes the route domain 1 has it's own default route: default-route-rd1 default%1 gw 192.168.120.254%1 static- flicky2000_1616Sorry - just to add. And the default route rd1 is working as it's being used for me to get to the SMTP server on the DMZ for management. In fact it's the only route in that route domain (SMTP server directly connected so no routing required for that IP range).
nitass_89166Noctilucent
So when you create the wildcard forwarder - should it be green?
it won't because ip forwarding virtual server does not have pool. it will be green when pool is up.
I don't see it exit the box on the other vlan interface that faces the internet firewall.
have you configured default route for route domain 1 (0.0.0.0%1/0) on bigip?
- flicky2000_1616nitass - I think that answers my first point. That the wildcard ip forwarding server would be blue in normal state as they can;t have pools associated to them - so the F5 box must understand this and say I will forward the traffic anyway cos it's a wildcard one. Yes the route domain 1 has it's own default route: default-route-rd1 default%1 gw 192.168.120.254%1 static
- flicky2000_1616Sorry - just to add. And the default route rd1 is working as it's being used for me to get to the SMTP server on the DMZ for management. In fact it's the only route in that route domain (SMTP server directly connected so no routing required for that IP range).
- nitass
I can see an SMTP request from the DMZ SMTP server to another server hit the F5 on the DMZ vlan interface by doing a tcpdump. I don't see it exit the box on the other vlan interface that faces the internet firewall.
if route is there, you should see egress packet. if you want, you can try wildcard performance layer 4 virtual server (instead of wildcard ip forwarding virtual server) and use gateway (192.168.120.254%1:any) as a pool.
when you did not see packet out, did you see reset? if yes, you may try to log reset cause.
sol13223: Configuring the BIG-IP system to log TCP RST packets
https://support.f5.com/kb/en-us/solutions/public/13000/200/sol13223.html- flicky2000_1616no RST seen. This is the tcpdump from the DMZ vlan on the F5:
- flicky2000_1616[me@f5:Standby:Changes Pending] ~ tcpdump -nn -i DMZ-VLAN | grep 10.198.7.122
- flicky2000_1616for some reason won't let me post the tcpdump output to devcentral - keeps saying it's spam! Needless to say it's just SYN packets. Running the same trace on the internet firewall facing vlan - I see nothing. One thing to note but I don't think it matters - this is a cluster. Traffic groups with floating live traffic on rd0 are on the active box. This testing is being done on the standby box (but standby wouold only mean for floating traffic groups?). The default gateway for the DMZ FTP server is the non-floating self IP on the standby box. In fact there are no floating objects yet assocaited with rd1. NB. out of working hours I have also failed the floating traffic groups for the live traffic on rd0 over so the standby says Active. Just to see if that made any difference (I didn't think it would) - it didn't.
- nitass_89166
I can see an SMTP request from the DMZ SMTP server to another server hit the F5 on the DMZ vlan interface by doing a tcpdump. I don't see it exit the box on the other vlan interface that faces the internet firewall.
if route is there, you should see egress packet. if you want, you can try wildcard performance layer 4 virtual server (instead of wildcard ip forwarding virtual server) and use gateway (192.168.120.254%1:any) as a pool.
when you did not see packet out, did you see reset? if yes, you may try to log reset cause.
sol13223: Configuring the BIG-IP system to log TCP RST packets
https://support.f5.com/kb/en-us/solutions/public/13000/200/sol13223.html- flicky2000_1616no RST seen. This is the tcpdump from the DMZ vlan on the F5:
- flicky2000_1616[me@f5:Standby:Changes Pending] ~ tcpdump -nn -i DMZ-VLAN | grep 10.198.7.122
- flicky2000_1616for some reason won't let me post the tcpdump output to devcentral - keeps saying it's spam! Needless to say it's just SYN packets. Running the same trace on the internet firewall facing vlan - I see nothing. One thing to note but I don't think it matters - this is a cluster. Traffic groups with floating live traffic on rd0 are on the active box. This testing is being done on the standby box (but standby wouold only mean for floating traffic groups?). The default gateway for the DMZ FTP server is the non-floating self IP on the standby box. In fact there are no floating objects yet assocaited with rd1. NB. out of working hours I have also failed the floating traffic groups for the live traffic on rd0 over so the standby says Active. Just to see if that made any difference (I didn't think it would) - it didn't.
- nitass_89166
This testing is being done on the standby box (but standby wouold only mean for floating traffic groups?).
what is traffic group of virtual server address (0.0.0.0%1)? is it floating (e.g. traffic-group-1) or non-floating (e.g. traffic-group-local)?
- flicky2000_1616it is the non floating local only traffic group.
- nitass_89166it should work but it seems it does not work here too. i tested in default route domain in 11.6.0.
- nitass
This testing is being done on the standby box (but standby wouold only mean for floating traffic groups?).
what is traffic group of virtual server address (0.0.0.0%1)? is it floating (e.g. traffic-group-1) or non-floating (e.g. traffic-group-local)?
- flicky2000_1616it is the non floating local only traffic group.
- nitassit should work but it seems it does not work here too. i tested in default route domain in 11.6.0.
- flicky2000_1616
Thanks I will test it with a floating traffic group (when live it will be a floating) - we have another slot this coming week where we can test. But it would imply that this could be a bug as we would expect it to work to a local traffic group as well.
- nitassyes, i think so. i am checking with support team.
- nitasstraffic-group-local-only does not work. developer filed ID529395 to track whether it is expected behavior or a bug. ID529395 Local-only network IP forwarding virtual server not forwarding traffic on standby system cr. porntep, eugene, paul, carl
- flicky2000_1616
I have now put the wildcard vs into a test floating traffic group that is active on our standby F5. The wildcard vs now works. Thanks very much for your input! I had raised a seperate case with F5 to look at it under the support contract we have. I will let them know this outcome.
Amit585731Flicky, Can you please explain what was done here to resolve the issue? I think we are also having the similar issue.- flicky2000_1616Hi Amit. As stated above the wildcard vs would not work when it was in the local only traffic group. As soon as I moved it into a floating traffic group it worked fine. Hope that helps.